From w3c-dist-auth-request@w3.org Wed Dec 1 13:51:19 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09077 for ; Wed, 1 Dec 2004 13:51:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZZVL-0005HV-7D for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 18:47:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZZVL-0005H1-0w for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 18:47:07 +0000 Received: from cats-mx2.ucsc.edu ([128.114.125.35]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZZVE-0007nb-5U for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 18:47:00 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx2.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB1Ij9KK003677 for ; Wed, 1 Dec 2004 10:45:12 -0800 (PST) Message-Id: <200412011845.iB1Ij9KK003677@cats-mx2.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Wed, 1 Dec 2004 10:45:02 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTWkPSR7t6fMOdoSJmqXOE8uW+pHwBQkHPA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412011845.iB1Ij9KK003677@cats-mx2.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9039 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 18:47:07 +0000 Content-Transfer-Encoding: 7bit Geoff Clemm wrote: Jim: I'm OK with adding the paragraph, but what was the possible misunderstanding that this additional text was intended to clear up? How else could a Depth=infinity COPY work? There are two possible confusions. 1) An implementer could implement the BINDDUP semantics (i.e., duplicate bindings, but not resources), rather than the desired semantics of duplicating resources and bindings. I agree that someone who reads and understands the current specification and RFC 2518 should not come to this misunderstanding. However, since the bind specification doesn't explicitly address Depth infinity copies, there is no explicit information that would clearly and definitively cause someone to stop thinking that BINDDUP semantics are the intent. 2) It's not clear how to handle bindings that cause containment loops, since in this case you do just want to only duplicate the binding, and not the bound resource. This is enough different from the mainline COPY semantics (duplicate binding and bound resource) that it's worth explicitly mentioning it. For example, a reasonable interpretation of the current specification, when copying loopback bindings, is to create a new binding to a new collection, where the new collection's bindings point to the resources bound by the collection originally pointed to by the loopback binding. This preserves the "copy binding and duplicate destination resource" semantics described for COPY. Note that people, in general, do not go out of their way to seek disconfirming evidence of positions they hold (see Reason's book on human error), and hence the burden really is on the spec. writer to provide text that clearly refutes alternate interpretations. > > * Section 2.6 -- there needs to be some discussion on the interactions of > > DAV:resource-id and versioning. As near as I can tell, the intent is that > > every revision will have a unique DAV:resource-id value. > > That's correct. I'm not sure why we would need to state this -- a > version resource clearly is not the same resource as it's VCR, so it > seems clear they'll never have the same DAV:resource-id. I agree with Julian. A version is a new resource created by the CHECKIN method. According to section 2.6, a new resource must be assigned a new resource-id, so each new version needs to be assigned a new, distinct resource-id. Glad we're in agreement. It should be trivial to add a sentence to this effect in the bind specification. > > * Section 6.2. I think it would be helpful to have an example including > > REBIND and locks, showing submission of one or more lock tokens in the If > > header. > > Such as one involving locked source and destination collections? That > may be useful. What do others think? I continue to believe that the right place for locking examples is in a locking spec, and that the binding spec just needs to make clear which resources and which URL mappings are being modified by an operation, since this is all you need to know which locks are required. I believe this information is well-defined in the pre-conditions of the methods introduced by the binding spec. So I'd vote not to add such an example, but I could live with it, if a majority is for it. I just wanted to clarify the use of the If header to pass lock tokens for already locked resources, since there have been client implementation issues concerning If implementation in this past. I agree that we should, for now, avoid discussion of the interactions of LOCK and bindings. - Jim From w3c-dist-auth-request@w3.org Wed Dec 1 14:46:53 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17043 for ; Wed, 1 Dec 2004 14:46:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZaPV-00041d-FT for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 19:45:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZaPU-000415-R3 for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 19:45:08 +0000 Received: from cats-mx4.ucsc.edu ([128.114.125.37]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZaPN-0001ga-SP for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 19:45:02 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx4.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB1JhW2B016123 for ; Wed, 1 Dec 2004 11:43:36 -0800 (PST) Message-Id: <200412011943.iB1JhW2B016123@cats-mx4.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Wed, 1 Dec 2004 11:43:25 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41ACDF1A.4050102@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTXH5gpEAPUY5RoQZ2bddRtF+Ni3wAvVu2A X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: BIND issue 3.2_example, was: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412011943.iB1JhW2B016123@cats-mx4.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9040 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 19:45:09 +0000 Content-Transfer-Encoding: 7bit Julian writes: > 3.2.1 Example for DAV:parent-set property *snip* > > > /CollX > x.gif > > > /CollX > y.gif > > Seems to me the href should hold a fully qualified URL, since other hrefs in the specification do this as well. - Jim PS -- While we're on the subject, I'll hold this up as an example of the kind of interpretation difference reasonable implementers can make of language that seems perfectly clear (and this is *much* more simple than the syntax for If headers). From w3c-dist-auth-request@w3.org Wed Dec 1 14:49:05 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17306 for ; Wed, 1 Dec 2004 14:49:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZaSR-00059H-6W for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 19:48:11 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZaSQ-00058R-Uq for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 19:48:10 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by bart.w3.org with esmtp (Exim 4.34) id 1CZaSQ-0005XN-8r for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 19:48:10 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB1JlVNO032535 for ; Wed, 1 Dec 2004 14:47:31 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB1JlVkb283032 for ; Wed, 1 Dec 2004 14:47:31 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB1JlV5C003562 for ; Wed, 1 Dec 2004 14:47:31 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB1JlVpk003559 for ; Wed, 1 Dec 2004 14:47:31 -0500 In-Reply-To: <200412011845.iB1Ij9KK003677@cats-mx2.ucsc.edu> To: "'WebDAV \(WebDAV WG\)'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 1 Dec 2004 14:47:39 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/01/2004 14:47:30, Serialize complete at 12/01/2004 14:47:30 Content-Type: multipart/alternative; boundary="=_alternative 006CBB2E85256F5D_=" Received-SPF: none (bart.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/OF5DCADE31.30C1DDD5-ON85256F5D.006812A3-85256F5D.006CBB34@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9041 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 19:48:11 +0000 This is a multipart message in MIME format. --=_alternative 006CBB2E85256F5D_= Content-Type: text/plain; charset="US-ASCII" Jim wrote on 12/01/2004 01:45:02 PM: > Geoff Clemm wrote: > > Jim: I'm OK with adding the paragraph, but what was the possible > misunderstanding > that this additional text was intended to clear up? How else could > a Depth=infinity > COPY work? > > There are two possible confusions. > > 1) An implementer could implement the BINDDUP semantics (i.e., duplicate > bindings, but not resources), rather than the desired semantics of > duplicating resources and bindings. I agree that someone who reads and > understands the current specification and RFC 2518 should not come to this > misunderstanding. However, since the bind specification doesn't explicitly > address Depth infinity copies, there is no explicit information that would > clearly and definitively cause someone to stop thinking that BINDDUP > semantics are the intent. > > 2) It's not clear how to handle bindings that cause containment loops, since > in this case you do just want to only duplicate the binding, and not the > bound resource. This is enough different from the mainline COPY semantics > (duplicate binding and bound resource) that it's worth explicitly mentioning > it. For example, a reasonable interpretation of the current specification, > when copying loopback bindings, is to create a new binding to a new > collection, where the new collection's bindings point to the resources bound > by the collection originally pointed to by the loopback binding. This > preserves the "copy binding and duplicate destination resource" semantics > described for COPY. OK, thanks, now I understand your concern. I suggest that rather than adding additional text, that we add an additional diagram showing what the result is of a copy in this case (I believe a single example can illustrate both of these points). Note: The reason I (and I believe Julian) push back on "just adding text" is that there are various ways to clarify (text, pictures, examples), and until we understand the specific problem, we cannot have a discussion about the best way to address the concern. > > > * Section 2.6 -- there needs to be some discussion on the > interactions of > > > DAV:resource-id and versioning. As near as I can tell, the > intent is that > > > every revision will have a unique DAV:resource-id value. > > > > That's correct. I'm not sure why we would need to state this -- a > > version resource clearly is not the same resource as it's VCR, so > it > > seems clear they'll never have the same DAV:resource-id. > > I agree with Julian. A version is a new resource created by the > CHECKIN method. > According to section 2.6, a new resource must be assigned a new > resource-id, > so each new version needs to be assigned a new, distinct > resource-id. > > Glad we're in agreement. It should be trivial to add a sentence to this > effect in the bind specification. I'm OK with adding this as the form of an example, i.e., in section 2.6, after the sentence stating that new resources get new resource-id's, we could say that "for example, when a new version resource is created, it receives a new resource-id". > > > * Section 6.2. I think it would be helpful to have an example > including > > > REBIND and locks, showing submission of one or more lock tokens > in the If > > > header. > > > > Such as one involving locked source and destination collections? > That > > may be useful. What do others think? > > I continue to believe that the right place for locking examples is > in a > locking spec, and that the binding spec just needs to make clear > which resources > and which URL mappings are being modified by an operation, since > this is all > you need to know which locks are required. I believe this > information is > well-defined in the pre-conditions of the methods introduced by the > binding > spec. So I'd vote not to add such an example, but I could live with > it, > if a majority is for it. > > I just wanted to clarify the use of the If header to pass lock tokens for > already locked resources, since there have been client implementation issues > concerning If implementation in this past. I agree that we should, for now, > avoid discussion of the interactions of LOCK and bindings. I agree. The last thing I want us to do is make a statement about lock token marshalling in the binding specification. Cheers, Geoff --=_alternative 006CBB2E85256F5D_= Content-Type: text/html; charset="US-ASCII"
Jim wrote on 12/01/2004 01:45:02 PM:

> Geoff Clemm wrote:
>
>    Jim: I'm OK with adding the paragraph, but what was the possible
> misunderstanding
>    that this additional text was intended to clear up?  How else could
> a Depth=infinity
>    COPY work?
>
> There are two possible confusions.
>
> 1) An implementer could implement the BINDDUP semantics (i.e., duplicate
> bindings, but not resources), rather than the desired semantics of
> duplicating resources and bindings. I agree that someone who reads and
> understands the current specification and RFC 2518 should not come to this
> misunderstanding. However, since the bind specification doesn't explicitly
> address Depth infinity copies, there is no explicit information that would
> clearly and definitively cause someone to stop thinking that BINDDUP
> semantics are the intent.
>
> 2) It's not clear how to handle bindings that cause containment loops, since
> in this case you do just want to only duplicate the binding, and not the
> bound resource. This is enough different from the mainline COPY semantics
> (duplicate binding and bound resource) that it's worth explicitly mentioning
> it. For example, a reasonable interpretation of the current specification,
> when copying loopback bindings, is to create a new binding to a new
> collection, where the new collection's bindings point to the resources bound
> by the collection originally pointed to by the loopback binding. This
> preserves the "copy binding and duplicate destination resource" semantics
> described for COPY.

OK, thanks, now I understand your concern.

I suggest that rather than adding additional text, that we add an additional
diagram showing what the result is of a copy in this case (I believe a
single example can illustrate both of these points).

Note: The reason I (and I believe Julian) push back on "just adding text"
is that there are various ways to clarify (text, pictures, examples), and
until we understand the specific problem, we cannot have a discussion about
the best way to address the concern.

>    > > * Section 2.6 -- there needs to be some discussion on the
> interactions of
>    > > DAV:resource-id and versioning. As near as I can tell, the
> intent is that
>    > > every revision will have a unique DAV:resource-id value.
>    >
>    > That's correct. I'm not sure why we would need to state this -- a
>    > version resource clearly is not the same resource as it's VCR, so
> it
>    > seems clear they'll never have the same DAV:resource-id.
>    
>    I agree with Julian.  A version is a new resource created by the
> CHECKIN method.
>    According to section 2.6, a new resource must be assigned a new
> resource-id,
>    so each new version needs to be assigned a new, distinct
> resource-id.
>
> Glad we're in agreement. It should be trivial to add a sentence to this
> effect in the bind specification.

I'm OK with adding this as the form of an example, i.e., in section 2.6,
after the sentence stating that new resources get new resource-id's, we
could say that "for example, when a new version resource is created, it
receives a new resource-id".

>    > > * Section 6.2. I think it would be helpful to have an example
> including
>    > > REBIND and locks, showing submission of one or more lock tokens
> in the If
>    > > header.
>    >
>    > Such as one involving locked source and destination collections?
> That
>    > may be useful. What do others think?
>    
>    I continue to believe that the right place for locking examples is
> in a
>    locking spec, and that the binding spec just needs to make clear
> which resources
>    and which URL mappings are being modified by an operation, since
> this is all
>    you need to know which locks are required.  I believe this
> information is
>    well-defined in the pre-conditions of the methods introduced by the
> binding
>    spec.  So I'd vote not to add such an example, but I could live with
> it,
>    if a majority is for it.
>
> I just wanted to clarify the use of the If header to pass lock tokens for
> already locked resources, since there have been client implementation issues
> concerning If implementation in this past. I agree that we should, for now,
> avoid discussion of the interactions of LOCK and bindings.
I agree.  The last thing I want us to do is make a statement about
lock token marshalling in the binding specification.

Cheers,
Geoff

--=_alternative 006CBB2E85256F5D_=-- From w3c-dist-auth-request@w3.org Wed Dec 1 15:00:29 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17992 for ; Wed, 1 Dec 2004 15:00:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZadD-0001cY-9J for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 19:59:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZadD-0001bu-2R for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 19:59:19 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZad5-00060a-Sv for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 19:59:12 +0000 Received: (qmail 23924 invoked by uid 65534); 1 Dec 2004 19:58:45 -0000 Received: from pD9E51B50.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.27.80) by mail.gmx.net (mp026) with SMTP; 01 Dec 2004 20:58:45 +0100 X-Authenticated: #1915285 Message-ID: <41AE226C.8030404@gmx.de> Date: Wed, 01 Dec 2004 20:58:36 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412011943.iB1JhW2B016123@cats-mx4.ucsc.edu> In-Reply-To: <200412011943.iB1JhW2B016123@cats-mx4.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND issue 3.2_example, was: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AE226C.8030404@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9042 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 19:59:19 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Julian writes: > > >>3.2.1 Example for DAV:parent-set property > > > *snip* > > >> >> >> /CollX >> x.gif >> >> >> /CollX >> y.gif >> >> > > > Seems to me the href should hold a fully qualified URL, since other hrefs in > the specification do this as well. It may hold whatever RFC2518 defines for DAV:href (we probably should let the DTD fragment refer to RFC2518, section 12.3, right?). RFC2518 relies on RFC2068, section 3.2.1, which allows both absoluteURI and relativeURI. > PS -- While we're on the subject, I'll hold this up as an example of the > kind of interpretation difference reasonable implementers can make of > language that seems perfectly clear (and this is *much* more simple than the > syntax for If headers). I don't see the issue here. Lots of WebDAV servers return relativeURIs in DAV:href elements, and as far as I can tell, this is no problem at all. Please explain :-) Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Dec 1 15:02:31 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18088 for ; Wed, 1 Dec 2004 15:02:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZafU-0002zk-UM for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 20:01:40 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZafU-0002zB-NS for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 20:01:40 +0000 Received: from cats-mx4.ucsc.edu ([128.114.125.37]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZafN-0006wv-RJ for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 20:01:34 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx4.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB1JurjR019374; Wed, 1 Dec 2004 11:56:56 -0800 (PST) Message-Id: <200412011956.iB1JurjR019374@cats-mx4.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Geoffrey M Clemm'" , "'WebDAV \(WebDAV WG\)'" Date: Wed, 1 Dec 2004 11:56:46 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTXBenEdSt2yEsOSGuGHEXEYBnb1gA2HZXQ X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412011956.iB1JurjR019374@cats-mx4.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9044 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 20:01:40 +0000 Content-Transfer-Encoding: 7bit Geoff writes: OK, since I don't feel strongly about this, I'm happy to defer to Julian's preference. I agree. - Jim From w3c-dist-auth-request@w3.org Wed Dec 1 15:04:22 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18242 for ; Wed, 1 Dec 2004 15:04:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZahH-00043V-Nq for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 20:03:31 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZahG-00042j-Fr for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 20:03:30 +0000 Received: from cats-mx4.ucsc.edu ([128.114.125.37]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZah9-0007jN-4h for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 20:03:23 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx4.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB1K1Xdt020447 for ; Wed, 1 Dec 2004 12:01:36 -0800 (PST) Message-Id: <200412012001.iB1K1Xdt020447@cats-mx4.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Wed, 1 Dec 2004 12:01:26 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41ACC8C5.6040001@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTXEjraaHPbR1Y1Sx6CrSsaj8R8rAAzcqKA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412012001.iB1K1Xdt020447@cats-mx4.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9045 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 20:03:31 +0000 Content-Transfer-Encoding: 7bit Julian writes: > >>>* Section 4. Need a new condition to cover the case where the BIND > >>>half-succeeded, and then needed to be rewound. This > condition would > >>>address the case where Overwrite is true, the destination > >> > >>binding has > >> > >>>been removed, but the new binding couldn't be created. > >> > >>But then it wouldn't be atomic, right? > > > > > > Well, what status element would you return in the case where the > > method half-succeeded, and then needed to re rewound? > > That depends on why the new binding couldn't be created....? Say, for the sake of argument, that there is a disk full condition, such that the database holding bindings could delete a binding, but couldn't create the new binding. In this internal server error condition, what status code/element would be returned? > I'm not seeing a problem (yet). C1 would be removed, while C2 > wouldn't. > It's the server's job to ensure that resource R isn't > negatively affected. OK, I'll let this one go. > Could you be more specific about which case you think would > need to be clarified? Is this about the specific marshalling > of REBIND, or about locking semantics in face of multiple bindings? It's about the problems clients have with correctly marshalling needed information into the If header. > It's way "everybody" does it (WebDAV lock tokens, WebDAV > ordering, Atom IDs, XML namespaces). Also, UUIDs may not > always be the best identifier available. For instance, for > lock tokens a server may be using a single UUID + a counter > (as allowed in the opaquelockoken syntax) -- why shouldn't it > do the same for resource IDs? OK, I'll let this one go. - Jim From w3c-dist-auth-request@w3.org Wed Dec 1 15:12:27 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19220 for ; Wed, 1 Dec 2004 15:12:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZaop-0007mR-Ij for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 20:11:19 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZaop-0007ls-3c for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 20:11:19 +0000 Received: from cats-mx1.ucsc.edu ([128.114.125.34]) by bart.w3.org with esmtp (Exim 4.34) id 1CZaoo-00079o-SF for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 20:11:19 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx1.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB1KAKHK021864 for ; Wed, 1 Dec 2004 12:10:23 -0800 (PST) Message-Id: <200412012010.iB1KAKHK021864@cats-mx1.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Wed, 1 Dec 2004 12:10:12 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41AE226C.8030404@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTX4FasluuHVO6RSJiYBWVPbu/t/wAAGFeA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: BIND issue 3.2_example, was: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412012010.iB1KAKHK021864@cats-mx1.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9046 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 20:11:19 +0000 Content-Transfer-Encoding: 7bit After refreshing my memory on relative URL calculation, I now agree the example is right. Is there anyplace in the DAV specifications where we state what URL should be used as the base URL for relative URL calculation? I don't think this is in 2518 anyplace. Did this make it into 2518bis? - Jim > > Seems to me the href should hold a fully qualified URL, since other > > hrefs in the specification do this as well. > > It may hold whatever RFC2518 defines for DAV:href (we > probably should let the DTD fragment refer to RFC2518, > section 12.3, right?). RFC2518 relies on RFC2068, section > 3.2.1, which allows both absoluteURI and relativeURI. > > > PS -- While we're on the subject, I'll hold this up as an > example of > > the kind of interpretation difference reasonable > implementers can make > > of language that seems perfectly clear (and this is *much* > more simple > > than the syntax for If headers). > > I don't see the issue here. Lots of WebDAV servers return > relativeURIs in DAV:href elements, and as far as I can tell, > this is no problem at all. Please explain :-) From w3c-dist-auth-request@w3.org Wed Dec 1 15:13:20 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19316 for ; Wed, 1 Dec 2004 15:13:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZapp-0008AI-AN for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 20:12:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZapo-00088x-At for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 20:12:20 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZaph-00026b-3J for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 20:12:13 +0000 Received: (qmail 31986 invoked by uid 65534); 1 Dec 2004 20:11:47 -0000 Received: from pD9E51B50.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.27.80) by mail.gmx.net (mp010) with SMTP; 01 Dec 2004 21:11:47 +0100 X-Authenticated: #1915285 Message-ID: <41AE257C.20208@gmx.de> Date: Wed, 01 Dec 2004 21:11:40 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412012001.iB1K1Xdt020447@cats-mx4.ucsc.edu> In-Reply-To: <200412012001.iB1K1Xdt020447@cats-mx4.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AE257C.20208@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9047 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 20:12:21 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: >>That depends on why the new binding couldn't be created....? > > > Say, for the sake of argument, that there is a disk full condition, such > that the database holding bindings could delete a binding, but couldn't > create the new binding. In this internal server error condition, what status > code/element would be returned? OK. I think the answer would be: none specific. The status would be just 506. There are many potential error conditions for which BIND doesn't define specific names. As a matter of fact, I'd say it's not possible to enumerate them all. >>Could you be more specific about which case you think would >>need to be clarified? Is this about the specific marshalling >>of REBIND, or about locking semantics in face of multiple bindings? > > > It's about the problems clients have with correctly marshalling needed > information into the If header. OK, just to clarify: you'd like to see an example for lock tokens being submitted in a non-trivial namespace operation such as MOVE/REBIND between locked collections? I'm not strongly opposed to that; I just like to understand the motivation (which in this case would be: we don't have an example like that in RFC2518, so this may be an action item for RFC2518bis as well). >>It's way "everybody" does it (WebDAV lock tokens, WebDAV >>ordering, Atom IDs, XML namespaces). Also, UUIDs may not >>always be the best identifier available. For instance, for >>lock tokens a server may be using a single UUID + a counter >>(as allowed in the opaquelockoken syntax) -- why shouldn't it >>do the same for resource IDs? > > > OK, I'll let this one go. Thanks :-) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Dec 1 15:18:59 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20165 for ; Wed, 1 Dec 2004 15:18:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZav2-0001ww-EC for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 20:17:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZav0-0001wA-EU for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 20:17:42 +0000 Received: from cats-mx4.ucsc.edu ([128.114.125.37]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZaut-0003mZ-J8 for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 20:17:35 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx4.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB1KG96j023739 for ; Wed, 1 Dec 2004 12:16:12 -0800 (PST) Message-Id: <200412012016.iB1KG96j023739@cats-mx4.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Wed, 1 Dec 2004 12:16:02 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTX3r+SO6d1F3SgSWyUHdzcFWRdXQAAytlg X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412012016.iB1KG96j023739@cats-mx4.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9048 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 20:17:44 +0000 Content-Transfer-Encoding: 7bit Geoff writes: OK, thanks, now I understand your concern. I suggest that rather than adding additional text, that we add an additional diagram showing what the result is of a copy in this case (I believe a single example can illustrate both of these points). This seems reasonable to me (depending on the example, of course). I'm OK with adding this as the form of an example, i.e., in section 2.6, after the sentence stating that new resources get new resource-id's, we could say that "for example, when a new version resource is created, it receives a new resource-id". That's fine with me, and let's mention VCRs while we're at it. - Jim From w3c-dist-auth-request@w3.org Wed Dec 1 15:21:01 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20377 for ; Wed, 1 Dec 2004 15:21:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZaxO-0003Cn-Bb for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 20:20:10 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZaxM-0003Bc-Gi for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 20:20:08 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZaxF-0004Uh-KK for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 20:20:01 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB1KIHxs022402 for ; Wed, 1 Dec 2004 12:18:21 -0800 (PST) Message-Id: <200412012018.iB1KIHxs022402@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Wed, 1 Dec 2004 12:18:10 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41AE257C.20208@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTX4iNqTzvbgBs2T/OFKv29SFUdvAAAIVGA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412012018.iB1KIHxs022402@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9049 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 20:20:10 +0000 Content-Transfer-Encoding: 7bit > I think the answer would be: none specific. The status would > be just 506. There are many potential error conditions for > which BIND doesn't define specific names. As a matter of > fact, I'd say it's not possible to enumerate them all. OK, then I'm fine with letting this issue go. > OK, just to clarify: you'd like to see an example for lock > tokens being submitted in a non-trivial namespace operation > such as MOVE/REBIND between locked collections? I'm not > strongly opposed to that; I just like to understand the > motivation (which in this case would be: we don't have an > example like that in RFC2518, so this may be an action item > for RFC2518bis as well). Yes, that's correct. I'm fine with this being added as an action item for 2518bis as well. - Jim From w3c-dist-auth-request@w3.org Wed Dec 1 15:23:35 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20656 for ; Wed, 1 Dec 2004 15:23:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZazp-0004W6-PE for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 20:22:41 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZazo-0004VM-PK for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 20:22:40 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CZazo-0002Rg-5j for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 20:22:40 +0000 Received: (qmail 26965 invoked by uid 65534); 1 Dec 2004 20:22:06 -0000 Received: from pD9E51B50.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.27.80) by mail.gmx.net (mp015) with SMTP; 01 Dec 2004 21:22:06 +0100 X-Authenticated: #1915285 Message-ID: <41AE27E3.4090004@gmx.de> Date: Wed, 01 Dec 2004 21:21:55 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'WebDAV (WebDAV WG)'" CC: ejw@cs.ucsc.edu References: <200412011943.iB1JhW2B016123@cats-mx4.ucsc.edu> <41AE226C.8030404@gmx.de> In-Reply-To: <41AE226C.8030404@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND issue 3.2_example, was: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AE27E3.4090004@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9050 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 20:22:41 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > ... > It may hold whatever RFC2518 defines for DAV:href (we probably should > let the DTD fragment refer to RFC2518, section 12.3, right?). RFC2518 > ... We can do this by 1) explicitly mentioning DAV:href in 1.1 (terminology imported from RFC2518), or 2) adding a to each of the DTD fragments. Any preferences (or alternative proposals)? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Dec 1 15:30:38 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21055 for ; Wed, 1 Dec 2004 15:30:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZb6O-0007nM-Bw for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 20:29:28 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZb6N-0007mm-TY for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 20:29:27 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CZb6N-0004yo-Ic for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 20:29:27 +0000 Received: (qmail 839 invoked by uid 65534); 1 Dec 2004 20:28:55 -0000 Received: from pD9E51B50.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.27.80) by mail.gmx.net (mp027) with SMTP; 01 Dec 2004 21:28:55 +0100 X-Authenticated: #1915285 Message-ID: <41AE2981.6060009@gmx.de> Date: Wed, 01 Dec 2004 21:28:49 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: "'WebDAV (WebDAV WG)'" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AE2981.6060009@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9051 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 20:29:28 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > There are two possible confusions. > > > > 1) An implementer could implement the BINDDUP semantics (i.e., duplicate > > bindings, but not resources), rather than the desired semantics of > > duplicating resources and bindings. I agree that someone who reads and > > understands the current specification and RFC 2518 should not come to > this > > misunderstanding. However, since the bind specification doesn't > explicitly > > address Depth infinity copies, there is no explicit information that > would > > clearly and definitively cause someone to stop thinking that BINDDUP > > semantics are the intent. > > > > 2) It's not clear how to handle bindings that cause containment > loops, since > > in this case you do just want to only duplicate the binding, and not the > > bound resource. This is enough different from the mainline COPY semantics > > (duplicate binding and bound resource) that it's worth explicitly > mentioning > > it. For example, a reasonable interpretation of the current > specification, > > when copying loopback bindings, is to create a new binding to a new > > collection, where the new collection's bindings point to the > resources bound > > by the collection originally pointed to by the loopback binding. This > > preserves the "copy binding and duplicate destination resource" semantics > > described for COPY. > > OK, thanks, now I understand your concern. > > I suggest that rather than adding additional text, that we add an > additional > diagram showing what the result is of a copy in this case (I believe a > single example can illustrate both of these points). OK. Any proposed text/artwork for inclusion into the spec? (I'll work on the other issues in the meantime :-). > Note: The reason I (and I believe Julian) push back on "just adding text" > is that there are various ways to clarify (text, pictures, examples), and > until we understand the specific problem, we cannot have a discussion about > the best way to address the concern. Agreed. In particular, when I myself read specs that (under my impression) repeat information that was already provided before/by reference, I start asking myself: "why are they repeating this? -- is this intended to *change* something that was said before?". So, if something's just intended to repeat something that was already specified somewhere else, it makes a lot of sense to say that, instead of leaving readers like myself confused :-) > > > > * Section 2.6 -- there needs to be some discussion on the > > interactions of > > > > DAV:resource-id and versioning. As near as I can tell, the > > intent is that > > > > every revision will have a unique DAV:resource-id value. > > > > > > That's correct. I'm not sure why we would need to state this -- a > > > version resource clearly is not the same resource as it's VCR, so > > it > > > seems clear they'll never have the same DAV:resource-id. > > > > I agree with Julian. A version is a new resource created by the > > CHECKIN method. > > According to section 2.6, a new resource must be assigned a new > > resource-id, > > so each new version needs to be assigned a new, distinct > > resource-id. > > > > Glad we're in agreement. It should be trivial to add a sentence to this > > effect in the bind specification. > > I'm OK with adding this as the form of an example, i.e., in section 2.6, > after the sentence stating that new resources get new resource-id's, we > could say that "for example, when a new version resource is created, it > receives a new resource-id". Sounds like a good compromise. Unless there are objections, I'll make that change right away. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Dec 1 15:36:58 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21443 for ; Wed, 1 Dec 2004 15:36:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZbCV-0002xz-BW for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 20:35:47 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZbCU-0002xL-Rk for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 20:35:46 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CZbCU-0007nf-EW for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 20:35:46 +0000 Received: (qmail 13067 invoked by uid 65534); 1 Dec 2004 20:35:14 -0000 Received: from pD9E51B50.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.27.80) by mail.gmx.net (mp016) with SMTP; 01 Dec 2004 21:35:14 +0100 X-Authenticated: #1915285 Message-ID: <41AE2AFC.3070005@gmx.de> Date: Wed, 01 Dec 2004 21:35:08 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412012010.iB1KAKHK021864@cats-mx1.ucsc.edu> In-Reply-To: <200412012010.iB1KAKHK021864@cats-mx1.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND issue 3.2_example, was: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AE2AFC.3070005@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9052 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 20:35:47 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > After refreshing my memory on relative URL calculation, I now agree the > example is right. Is there anyplace in the DAV specifications where we state > what URL should be used as the base URL for relative URL calculation? I > don't think this is in 2518 anyplace. Did this make it into 2518bis? RFC2518bis attempts to clarify this (however I'm not yet happy with the way it does it :-). Apache/moddav routinely returns DAV:href elements containing relativeURI starting with a "/", which doesn't seem to cause any interop problems in practice (of course, returning non-root relativeURI will be way more interesting, but that's something RFC2518bis should resolve). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Dec 1 15:49:50 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18089 for ; Wed, 1 Dec 2004 15:02:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZafR-0002ys-NY for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 20:01:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZafR-0002yO-HJ for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 20:01:37 +0000 Received: from cats-mx4.ucsc.edu ([128.114.125.37]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZafK-0006wv-JU for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 20:01:30 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx4.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB1JurjQ019374 for ; Wed, 1 Dec 2004 11:56:56 -0800 (PST) Message-Id: <200412011956.iB1JurjQ019374@cats-mx4.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Wed, 1 Dec 2004 11:56:46 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41ACB92B.3030108@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTXCPhgvlo7+3GfQxiKL5O2wTOFZwA1YR4g X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412011956.iB1JurjQ019374@cats-mx4.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9043 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 20:01:37 +0000 Content-Transfer-Encoding: 7bit Julian and Lisa write: > >> I agree with Julian. A version is a new resource created by the > >> CHECKIN method. > >> According to section 2.6, a new resource must be assigned a new > >> resource-id, so each new version needs to be assigned a > new, distinct > >> resource-id. > > > > Great -- so we agree on what should happen. As Jim suggests, let's > > put it in the spec. > > Again, before we put additional spec into the spec, it should > be clear what problem it solves. I understand that you lean > to "more is better", but please acknowledge that many people > writing specs disagree. The problem concerns the definition of "resource" and "identity" you use in developing your implementation of DAV:resource-id. Since the discussion of DAV:resource-id does not specifically discuss versioning, someone could read the DeltaV spec and the bind specification, and reasonably assume that the authors of the bind specification hadn't actually thought about the interactions of DAV:resource-id and versioning. In this case, that same reader might then think that the intent was to give each logical resource (e.g., the abstract concept of all versions of a document) a unique identifier, rather than each version. Such a person might then make their implementation give each version in a version history the same DAV:resource-id, and then have each VCR associated with this version history expose the same DAV:resource-id. While a very careful reading of both specifications would lead you to not do this, I'll stress again that we need to assume the person with the incorrect model will not be actively seeking disconfirming evidence. > I'm not sure how locking examples for REBIND are going to help much. > REBIND is just like MOVE, except for slightly different > marshalling. I'm > not against adding an example per se, but if we do it it > should really > contain something that's not available elsewhere. There have been many client implementation problems with the If header. More examples might help reduce these implementation problems. - Jim From w3c-dist-auth-request@w3.org Wed Dec 1 15:55:34 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23305 for ; Wed, 1 Dec 2004 15:55:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZbUH-0002YP-6I for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 20:54:09 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZbUF-0002X8-M9; Wed, 01 Dec 2004 20:54:07 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by bart.w3.org with esmtp (Exim 4.34) id 1CZbUF-0005qU-9H; Wed, 01 Dec 2004 20:54:07 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB1KraF7007083; Wed, 1 Dec 2004 15:53:36 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB1Krajf254110; Wed, 1 Dec 2004 15:53:36 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB1KrZJa018690; Wed, 1 Dec 2004 15:53:35 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB1KrZ26018684; Wed, 1 Dec 2004 15:53:35 -0500 In-Reply-To: <200412012016.iB1KG96j023739@cats-mx4.ucsc.edu> To: Cc: "'WebDAV \(WebDAV WG\)'" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 1 Dec 2004 15:53:39 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/01/2004 15:53:34, Serialize complete at 12/01/2004 15:53:34 Content-Type: multipart/alternative; boundary="=_alternative 0072C64B85256F5D_=" Received-SPF: none (bart.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/OFD0DEA995.66C29AD0-ON85256F5D.007213F9-85256F5D.0072C64D@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9053 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 20:54:09 +0000 This is a multipart message in MIME format. --=_alternative 0072C64B85256F5D_= Content-Type: text/plain; charset="US-ASCII" Jim wrote on 12/01/2004 03:16:02 PM: > Geoff writes: > I'm OK with adding this as the form of an example, i.e., in section 2.6, > after the sentence stating that new resources get new resource-id's, we > could say that "for example, when a new version resource is created, it > receives a new resource-id". > > That's fine with me, and let's mention VCRs while we're at it. Now that's a more interesting topic (:-). When you use the VERSION-CONTROL method with a specified Version, one could interpret that as just restoring that resource, as opposed to creating a new resource. I can imagine repository vendors having strong (contradictory :-) opinions on that topic, so I'd suggest maintaining a discrete silence on that topic for now (and if it needs to be resolved, do so in the RFC-3253bis, and not in the binding specification). Cheers, Geoff --=_alternative 0072C64B85256F5D_= Content-Type: text/html; charset="US-ASCII"
Jim wrote on 12/01/2004 03:16:02 PM:

> Geoff writes:
>    I'm OK with adding this as the form of an example, i.e., in section 2.6,
>    after the sentence stating that new resources get new resource-id's, we
>    could say that "for example, when a new version resource is created, it
>    receives a new resource-id".
>
> That's fine with me, and let's mention VCRs while we're at it.
Now that's a more interesting topic (:-).

When you use the VERSION-CONTROL method with a specified Version,
one could interpret that as just restoring that resource, as opposed
to creating a new resource.  I can imagine repository vendors having strong
(contradictory :-) opinions on that topic, so I'd suggest maintaining
a discrete silence on that topic for now (and if it needs to be resolved,
do so in the RFC-3253bis, and not in the binding specification).

Cheers,
Geoff
--=_alternative 0072C64B85256F5D_=-- From w3c-dist-auth-request@w3.org Wed Dec 1 17:13:18 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02715 for ; Wed, 1 Dec 2004 17:13:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZZ7a-0006aa-LJ for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Dec 2004 18:22:34 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZZ7Z-0006Zy-K2 for w3c-dist-auth@listhub.w3.org; Wed, 01 Dec 2004 18:22:33 +0000 Received: from scorpio.lunarpages.com ([64.235.234.122]) by bart.w3.org with esmtp (Exim 4.34) id 1CZZ7Z-0001uW-5g for w3c-dist-auth@w3.org; Wed, 01 Dec 2004 18:22:33 +0000 Received: from [65.198.79.71] (helo=[192.168.11.117]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.43) id 1CZZ6d-0003pV-Uq; Wed, 01 Dec 2004 10:21:36 -0800 In-Reply-To: <0B9AD7E7-4314-11D9-B57F-000A95B2BB72@osafoundation.org> References: <0B9AD7E7-4314-11D9-B57F-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDAV (WebDAV WG) From: "Roy T. Fielding" Date: Wed, 1 Dec 2004 10:21:31 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - w3.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Received-SPF: none (bart.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bindings and permissions X-Archived-At: http://www.w3.org/mid/D3551436-43C5-11D9-B695-000D93324AD6@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9038 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 01 Dec 2004 18:22:34 +0000 Content-Transfer-Encoding: 7bit On Nov 30, 2004, at 1:08 PM, Lisa Dusseault wrote: > I think I've discussed this before but it's come up again in a use > case I'm working on. In Chandler we want a user to be able to share > the same item (for example, a calendar event) in multiple collections. > For example, I might want to show the "OSAF holiday party" in both my > work calendar share and my home calendar share, so that other users > who view either my work or my home calendar will see the event > regardless (and users who share both won't see the event twice). > > The natural way to do this if the server supports bindings would be to > create the event in one collection, let's say the client will create > it in my work share where permissions are inherited so that all OSAF > people can view the event. Then BIND the event to the other > collection, where the inherited permissions normally would > automatically make it so that my family and friends can view the > event. That is the most natural way? I would think that the most natural way would be to have one universal calendar and, when you author an entry in any calendar, list within it the attributes (calendars/roles/groups/whatever) to which it applies. Your work and home calendars are therefore just virtual collections based on the universal calendar and an attribute mask. An attempt to author within any virtual calendar will create "bindings" (what everyone else calls resources) within all calendars to which the entry attributes apply. > I can imagine a server implementing it either way depending on what > they think the common use cases are; what can the client predict or > require here? If the client can predict it, then the application has become tightly-coupled between client and server. ....Roy From w3c-dist-auth-request@w3.org Wed Dec 1 20:06:17 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18489 for ; Wed, 1 Dec 2004 20:06:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZfOh-0004cX-IR for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 01:04:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZfOg-0004bp-CM for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 01:04:38 +0000 Received: from cats-mx2.ucsc.edu ([128.114.125.35]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZfOZ-0003RD-F0 for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 01:04:31 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx2.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB2148xU006275 for ; Wed, 1 Dec 2004 17:04:11 -0800 (PST) Message-Id: <200412020104.iB2148xU006275@cats-mx2.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Wed, 1 Dec 2004 17:04:00 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01BF_01C4D7C7.C681B6F0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41AE2981.6060009@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTX5IzrBSDo2v2zQpiGDy2CtaGV9gAIwmXw X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412020104.iB2148xU006275@cats-mx2.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9054 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 01:04:39 +0000 This is a multi-part message in MIME format. ------=_NextPart_000_01BF_01C4D7C7.C681B6F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > OK. Any proposed text/artwork for inclusion into the spec? > (I'll work on the other issues in the meantime :-). How about: As an example of how COPY with Depth infinity would work in the presence of bindings, consider the following collection: +------------------+ | Root Collection | | bindings: | | CollX | +------------------+ | | | +-------------------------------+ | Collection C1 |<-------+ | bindings: | | | x.gif CollY | | +-------------------------------+ | | \ | | \ (creates loop) | | \ | +-------------+ +------------------+ | | Resource R1 | | Collection C2 | | +-------------+ | bindings: | | | y.gif CollZ | | +------------------+ | | | | | +--------+ | +-------------+ | Resource R2 | +-------------+ If a COPY with Depth inifinity is submitted to /CollX, with destination of /CollA, the outcome of the copy operation is: +-------------------------+ | Root Collection | | bindings: | | CollX CollA | +-------------------------+ / \ / \ / \ / \ +-------------------------------+ +-------------------------------+ | Collection C1 |<-------+ | Collection C3 |<-------+ | bindings: | | | bindings: | | | x.gif CollY | | | x.gif CollY | | +-------------------------------+ | +-------------------------------+ | | \ | | \ | | \ (creates loop) | | \ (creates loop) | | \ | | \ | +-------------+ +------------------+ | +-------------+ +------------------+ | | Resource R1 | | Collection C2 | | | Resource R3 | | Collection C4 | | +-------------+ | bindings: | | +-------------+ | bindings: | | | y.gif CollZ | | | y.gif CollZ | | +------------------+ | +------------------+ | | | | | | | | +--------+ | +--------+ | | +-------------+ +-------------+ | Resource R2 | | Resource R4 | +-------------+ +-------------+ Unfortunately, this figure goes over the RFC column limit, so it'll need some tweaking before its in final form. - Jim ------=_NextPart_000_01BF_01C4D7C7.C681B6F0 Content-Type: text/plain; name="bind_fig.txt" Content-Disposition: attachment; filename="bind_fig.txt" Content-Transfer-Encoding: quoted-printable =0A= +-------------------------+=0A= | Root Collection |=0A= | bindings: |=0A= | CollX CollA |=0A= +-------------------------+=0A= / \=0A= / \=0A= / \=0A= / \=0A= +-------------------------------+ = +-------------------------------+=0A= | Collection C1 |<-------+ | Collection C3 = |<-------+=0A= | bindings: | | | bindings: = | |=0A= | x.gif CollY | | | x.gif CollY = | |=0A= +-------------------------------+ | = +-------------------------------+ |=0A= | \ | | \ = |=0A= | \ (creates loop) | | \ = (creates loop) |=0A= | \ | | \ = | =0A= +-------------+ +------------------+ | +-------------+ = +------------------+ |=0A= | Resource R1 | | Collection C2 | | | Resource R3 | | = Collection C4 | |=0A= +-------------+ | bindings: | | +-------------+ | = bindings: | |=0A= | y.gif CollZ | | | = y.gif CollZ | |=0A= +------------------+ | = +------------------+ |=0A= | | | = | | |=0A= | +--------+ = | +--------+=0A= | = | =0A= +-------------+ = +-------------+=0A= | Resource R2 | | = Resource R4 | =0A= +-------------+ = +-------------+ ------=_NextPart_000_01BF_01C4D7C7.C681B6F0-- From w3c-dist-auth-request@w3.org Wed Dec 1 20:22:47 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19561 for ; Wed, 1 Dec 2004 20:22:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZffW-0003sZ-Ck for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 01:22:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZffW-0003s1-39 for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 01:22:02 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZffP-0000On-76 for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 01:21:55 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB21Lsaa011146 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 1 Dec 2004 17:21:57 -0800 In-Reply-To: References: <0B9AD7E7-4314-11D9-B57F-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <89AC7963-4400-11D9-9DD0-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDAV (WebDAV WG) From: Lisa Dusseault Date: Wed, 1 Dec 2004 17:21:48 -0800 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bindings and permissions X-Archived-At: http://www.w3.org/mid/89AC7963-4400-11D9-9DD0-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9055 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 01:22:02 +0000 Content-Transfer-Encoding: 7bit On Dec 1, 2004, at 10:21 AM, Roy T. Fielding wrote: > On Nov 30, 2004, at 1:08 PM, Lisa Dusseault wrote: >> I think I've discussed this before but it's come up again in a use >> case I'm working on. In Chandler we want a user to be able to share >> the same item (for example, a calendar event) in multiple >> collections. For example, I might want to show the "OSAF holiday >> party" in both my work calendar share and my home calendar share, so >> that other users who view either my work or my home calendar will see >> the event regardless (and users who share both won't see the event >> twice). >> >> The natural way to do this if the server supports bindings would be >> to create the event in one collection, let's say the client will >> create it in my work share where permissions are inherited so that >> all OSAF people can view the event. Then BIND the event to the other >> collection, where the inherited permissions normally would >> automatically make it so that my family and friends can view the >> event. > > That is the most natural way? I would think that the most natural way > would be > to have one universal calendar and, when you author an entry in any > calendar, > list within it the attributes (calendars/roles/groups/whatever) to > which it applies. > Your work and home calendars are therefore just virtual collections > based on the > universal calendar and an attribute mask. An attempt to author within > any virtual > calendar will create "bindings" (what everyone else calls resources) > within all > calendars to which the entry attributes apply. > I've seen the "universal calendar" approach as well (called "one big soup"), so obviously there is more than one natural way but of course it depends on your network architecture and use cases. The big soup approach certainly works for one server site. But when you try to view one calendar on one site and another calendar on another site (run by different IT departments) things stop working the same way. So if you begin with the understanding that the user is going to access a set of calendars distributed across a set of repositories administered by different people, the big soup (on one site) starts to be a special case that is unnecessarily different from the general case. Another reason I didn't mention the big soup approach is because that requires server support. I'm working on a rich client and we'd rather minimize the number of new, specific features that must be added to the server in order to get this kind of scenario working. Finally, whenever you require special server support -- creating virtual collections based on event attributes -- that limits the flexibility of clients to decide for themselves how the collections should be structured. You could try to define a generic server feature to support this (e.g. dynamic-membership collections based on the results of a rule set) and return control to the client, but that generic server feature is nowhere near the level of support and standardization that bindings has. >> I can imagine a server implementing it either way depending on what >> they think the common use cases are; what can the client predict or >> require here? > > If the client can predict it, then the application has become > tightly-coupled > between client and server. > No, it just means that the range of options open to the server has been closed down to a smaller set of options. Defining a standard always involves that. I'm not suggesting full client predictability, that's impossible in practice. I still think it advisable to close down the options available to servers, in order to reduce unpredictability somewhat. Lisa From w3c-dist-auth-request@w3.org Wed Dec 1 20:29:50 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20072 for ; Wed, 1 Dec 2004 20:29:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZfmS-0006Ch-E1 for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 01:29:12 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZfmS-0006Bg-6b for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 01:29:12 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CZfmR-0003c4-UI for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 01:29:12 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB21Suaa011378 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 1 Dec 2004 17:29:04 -0800 In-Reply-To: <200412012018.iB1KIHxs022402@cats-mx3.ucsc.edu> References: <200412012018.iB1KIHxs022402@cats-mx3.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <84AD3812-4401-11D9-9DD0-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: "'WebDAV \(WebDAV WG\)'" From: Lisa Dusseault Date: Wed, 1 Dec 2004 17:28:49 -0800 To: X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/84AD3812-4401-11D9-9DD0-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9056 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 01:29:12 +0000 Content-Transfer-Encoding: 7bit >> OK, just to clarify: you'd like to see an example for lock >> tokens being submitted in a non-trivial namespace operation >> such as MOVE/REBIND between locked collections? I'm not >> strongly opposed to that; I just like to understand the >> motivation (which in this case would be: we don't have an >> example like that in RFC2518, so this may be an action item >> for RFC2518bis as well). > > Yes, that's correct. I'm fine with this being added as an action item > for > 2518bis as well. > > Sounds good... getting such an example into RFC sooner as well as later makes sense to me. Lisa From w3c-dist-auth-request@w3.org Wed Dec 1 20:37:21 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20745 for ; Wed, 1 Dec 2004 20:37:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZftZ-0001GB-8J for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 01:36:33 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZftZ-0001Fh-0l for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 01:36:33 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CZftY-0005Y6-N7 for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 01:36:32 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB21aAaa011571 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 1 Dec 2004 17:36:22 -0800 In-Reply-To: <41AE2981.6060009@gmx.de> References: <41AE2981.6060009@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8633B528-4402-11D9-9DD0-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: "'WebDAV (WebDAV WG)'" , Geoffrey M Clemm From: Lisa Dusseault Date: Wed, 1 Dec 2004 17:36:01 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Specification philosophies X-Archived-At: http://www.w3.org/mid/8633B528-4402-11D9-9DD0-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9057 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 01:36:33 +0000 Content-Transfer-Encoding: 7bit > > Agreed. In particular, when I myself read specs that (under my > impression) repeat information that was already provided before/by > reference, I start asking myself: "why are they repeating this? -- is > this intended to *change* something that was said before?". So, if > something's just intended to repeat something that was already > specified somewhere else, it makes a lot of sense to say that, instead > of leaving readers like myself confused :-) > This is confirming evidence for what I thought -- Julian, you have an extraordinarily good memory, even among this techie crowd! I do not find repeated information to be confusing because with my poorer short-term memory I have forgotten the details of what was already said. I also tend to read quickly and sometimes skip over details. Other readers fall along this range but I'm guessing Julian would be at nearly one extreme of fine memory/detail and me (I've always supposed) somewhere in the middle. Repetition need not be in the same form. I've noticed four different ways that functionality *should* be repeatedly described in a spec and there may be more: 1) Explain the model. 2) List the requirements, including those that follow from the model 3) Show one or more examples that meet the requirements and illustrate the model 4) Formal definition, schema (ABNF or DTD or other) of syntax When exactly the same thing needs to be repeated (e.g. method FOO has the same error conditions as method BAR) we can consider cut-and-paste of small sections, or using a table or some other way to make the information obvious. It's the silent or assumed references that scare me most. Lisa From w3c-dist-auth-request@w3.org Wed Dec 1 23:11:55 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13315 for ; Wed, 1 Dec 2004 23:11:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZiIQ-0004pu-W5 for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 04:10:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZiIP-0004p5-Lj for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 04:10:21 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZiII-0005BL-KF for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 04:10:14 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB249oNO026057 for ; Wed, 1 Dec 2004 23:09:50 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB249ojf273902 for ; Wed, 1 Dec 2004 23:09:50 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB249ojG012777 for ; Wed, 1 Dec 2004 23:09:50 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB249oax012773 for ; Wed, 1 Dec 2004 23:09:50 -0500 In-Reply-To: <200412020104.iB2148xU006275@cats-mx2.ucsc.edu> To: "'WebDAV \(WebDAV WG\)'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 1 Dec 2004 23:09:54 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/01/2004 23:09:49, Serialize complete at 12/01/2004 23:09:49 Content-Type: multipart/alternative; boundary="=_alternative 0016E01C85256F5E_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/OFAC57DAB8.29CA98BC-ON85256F5E.0015519E-85256F5E.0016E01D@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9058 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 04:10:22 +0000 This is a multipart message in MIME format. --=_alternative 0016E01C85256F5E_= Content-Type: text/plain; charset="US-ASCII" Thanks, Jim! Here's a reformatting which should avoid the column wrap problem. Cheers, Geoff +------------------+ | Root Collection | | bindings: | | CollX | +------------------+ | | | +-------------------------------+ | Collection C1 |<-------+ | bindings: | | | x.gif CollY | | +-------------------------------+ | | \ | | \ (creates loop) | | \ | +-------------+ +------------------+ | | Resource R1 | | Collection C2 | | +-------------+ | bindings: | | | y.gif CollZ | | +------------------+ | | | | | +--------+ | +-------------+ | Resource R2 | +-------------+ If a COPY with Depth inifinity is submitted to /CollX, with destination of /CollA, the outcome of the copy operation is: +------------------+ | Root Collection | | bindings: | | CollX CollA | +------------------+ | | | +--------------------------+ | | +-------------------+ | | Collection C1 |<------------------+ | | bindings: | | | | x.gif CollY | | | +-------------------+ | | | \ | | | \ (creates loop) | | | \ | | +-------------+ +-----------------+ | | | Resource R1 | | Collection C2 | | | +-------------+ | bindings: | | | | y.gif CollZ | | | +-----------------+ | | | | | | | +-------+ | | | +-------------+ | | Resource R2 | | +-------------+ | | +-------------------------------+ | | +-------------------+ | Collection C3 |<------------------+ | bindings: | | | x.gif CollY | | +-------------------+ | | \ | | \ (creates loop) | | \ | +-------------+ +-----------------+ | | Resource R3 | | Collection C4 | | +-------------+ | bindings: | | | y.gif CollZ | | +-----------------+ | | | | | +-------+ | +-------------+ | Resource R4 | +-------------+ w3c-dist-auth-request@w3.org wrote on 12/01/2004 08:04:00 PM: > > > OK. Any proposed text/artwork for inclusion into the spec? > > (I'll work on the other issues in the meantime :-). > > How about: > > As an example of how COPY with Depth infinity would work in the presence of > bindings, consider the following collection: > > +------------------+ > | Root Collection | > | bindings: | > | CollX | > +------------------+ > | > | > | > +-------------------------------+ > | Collection C1 |<-------+ > | bindings: | | > | x.gif CollY | | > +-------------------------------+ | > | \ | > | \ (creates loop) | > | \ | > +-------------+ +------------------+ | > | Resource R1 | | Collection C2 | | > +-------------+ | bindings: | | > | y.gif CollZ | | > +------------------+ | > | | | > | +--------+ > | > +-------------+ > | Resource R2 | > +-------------+ > > If a COPY with Depth inifinity is submitted to /CollX, with destination of > /CollA, the outcome of the copy operation is: > > +-------------------------+ > | Root Collection | > | bindings: | > | CollX CollA | > +-------------------------+ > / \ > / \ > / \ > / \ > +-------------------------------+ > +-------------------------------+ > | Collection C1 |<-------+ | Collection C3 > |<-------+ > | bindings: | | | bindings: > | | > | x.gif CollY | | | x.gif CollY > | | > +-------------------------------+ | > +-------------------------------+ | > | \ | | \ > | > | \ (creates loop) | | \ > (creates loop) | > | \ | | \ > | > +-------------+ +------------------+ | +-------------+ > +------------------+ | > | Resource R1 | | Collection C2 | | | Resource R3 | | > Collection C4 | | > +-------------+ | bindings: | | +-------------+ | > bindings: | | > | y.gif CollZ | | | y.gif > CollZ | | > +------------------+ | > +------------------+ | > | | | | > | | > | +--------+ | > +--------+ > | | > +-------------+ > +-------------+ > | Resource R2 | | > Resource R4 | > +-------------+ > +-------------+ > > > Unfortunately, this figure goes over the RFC column limit, so it'll need > some tweaking before its in final form. > > - Jim > [attachment "bind_fig.txt" deleted by Geoffrey M Clemm/Lexington/IBM] --=_alternative 0016E01C85256F5E_= Content-Type: text/html; charset="US-ASCII"
Thanks, Jim!  Here's a reformatting which should avoid the column wrap problem.
Cheers,
Geoff

+------------------+
| Root Collection  |
|  bindings:       |
|  CollX           |
+------------------+
   |
   |
   |
+-------------------------------+
| Collection C1                 |<-------+
| bindings:                     |        |
| x.gif      CollY              |        |
+-------------------------------+        |
   |          \                         |
   |           \         (creates loop) |
   |            \                       |
+-------------+   +------------------+   |
| Resource R1 |   | Collection C2    |   |
+-------------+   | bindings:        |   |
                 | y.gif     CollZ  |   |
                 +------------------+   |
                     |         |        |
                     |         +--------+
                     |
                 +-------------+
                 | Resource R2 |
                 +-------------+

If a COPY with Depth inifinity is submitted to /CollX, with destination of
/CollA, the outcome of the copy operation is:

+------------------+
| Root Collection  |
|  bindings:       |
|  CollX     CollA |
+------------------+
   |           |
   |           +--------------------------+
   |                                      |
+-------------------+                      |
| Collection C1     |<------------------+  |
| bindings:         |                   |  |
| x.gif      CollY  |                   |  |
+-------------------+                   |  |
   |          \                        |  |
   |           \        (creates loop) |  |
   |            \                      |  |
+-------------+   +-----------------+   |  |
| Resource R1 |   | Collection C2   |   |  |
+-------------+   | bindings:       |   |  |
                 | y.gif     CollZ |   |  |
                 +-----------------+   |  |
                     |         |       |  |
                     |         +-------+  |
                     |                    |
                 +-------------+          |
                 | Resource R2 |          |
                 +-------------+          |
                                          |
           +-------------------------------+
          |
          |
+-------------------+
| Collection C3     |<------------------+
| bindings:         |                   |
| x.gif      CollY  |                   |
+-------------------+                   |
   |          \                        |
   |           \        (creates loop) |
   |            \                      |
+-------------+   +-----------------+   |
| Resource R3 |   | Collection C4   |   |
+-------------+   | bindings:       |   |
                 | y.gif     CollZ |   |
                 +-----------------+   |
                     |         |       |
                     |         +-------+
                     |
                 +-------------+
                 | Resource R4 |
                 +-------------+


w3c-dist-auth-request@w3.org wrote on 12/01/2004 08:04:00 PM:

>
> > OK. Any proposed text/artwork for inclusion into the spec?
> > (I'll work on the other issues in the meantime :-).
>
> How about:
>
> As an example of how COPY with Depth infinity would work in the presence of
> bindings, consider the following collection:
>
> +------------------+
> | Root Collection  |
> |  bindings:       |
> |  CollX           |
> +------------------+
>     |
>     |
>     |
> +-------------------------------+
> | Collection C1                 |<-------+
> | bindings:                     |        |
> | x.gif      CollY              |        |
> +-------------------------------+        |
>     |          \                         |
>     |           \         (creates loop) |
>     |            \                       |
> +-------------+   +------------------+   |
> | Resource R1 |   | Collection C2    |   |
> +-------------+   | bindings:        |   |
>                   | y.gif     CollZ  |   |
>                   +------------------+   |
>                       |         |        |
>                       |         +--------+
>                       |
>                   +-------------+
>                   | Resource R2 |
>                   +-------------+
>
> If a COPY with Depth inifinity is submitted to /CollX, with destination of
> /CollA, the outcome of the copy operation is:
>
>                                 +-------------------------+
>                                 | Root Collection         |
>                                 |  bindings:              |
>                                 |  CollX          CollA   |
>                                 +-------------------------+
>                                     /               \
>                                    /                 \
>                                   /                   \
>                                  /                     \
> +-------------------------------+
> +-------------------------------+
> | Collection C1                 |<-------+         | Collection C3
> |<-------+
> | bindings:                     |        |         | bindings:
> |        |
> | x.gif      CollY              |        |         | x.gif      CollY
> |        |
> +-------------------------------+        |
> +-------------------------------+        |
>     |          \                         |             |          \
> |
>     |           \         (creates loop) |             |           \
> (creates loop) |
>     |            \                       |             |            \
> |  
> +-------------+   +------------------+   |         +-------------+
> +------------------+   |
> | Resource R1 |   | Collection C2    |   |         | Resource R3 |   |
> Collection C4    |   |
> +-------------+   | bindings:        |   |         +-------------+   |
> bindings:        |   |
>                   | y.gif     CollZ  |   |                           | y.gif
> CollZ  |   |
>                   +------------------+   |
> +------------------+   |
>                       |         |        |                               |
> |        |
>                       |         +--------+                               |
> +--------+
>                       |                                                  |
>                   +-------------+
> +-------------+
>                   | Resource R2 |                                    |
> Resource R4 |
>                   +-------------+
> +-------------+
>
>
> Unfortunately, this figure goes over the RFC column limit, so it'll need
> some tweaking before its in final form.
>
> - Jim
> [attachment "bind_fig.txt" deleted by Geoffrey M Clemm/Lexington/IBM] --=_alternative 0016E01C85256F5E_=-- From w3c-dist-auth-request@w3.org Thu Dec 2 03:50:13 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20756 for ; Thu, 2 Dec 2004 03:50:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZmdE-00038V-5K for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 08:48:08 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZmdC-00037B-G5 for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 08:48:06 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CZmdB-0002gs-9j for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 08:48:06 +0000 Received: (qmail 12174 invoked by uid 65534); 2 Dec 2004 08:47:32 -0000 Received: from pD9E51B50.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.27.80) by mail.gmx.net (mp014) with SMTP; 02 Dec 2004 09:47:32 +0100 X-Authenticated: #1915285 Message-ID: <41AED69F.9050200@gmx.de> Date: Thu, 02 Dec 2004 09:47:27 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: "'WebDAV (WebDAV WG)'" , Geoffrey M Clemm References: <41AE2981.6060009@gmx.de> <8633B528-4402-11D9-9DD0-000A95B2BB72@osafoundation.org> In-Reply-To: <8633B528-4402-11D9-9DD0-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Specification philosophies X-Archived-At: http://www.w3.org/mid/41AED69F.9050200@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9059 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 08:48:08 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > ... > short-term memory I have forgotten the details of what was already > said. I also tend to read quickly and sometimes skip over details. > Other readers fall along this range but I'm guessing Julian would be at > nearly one extreme of fine memory/detail and me (I've always supposed) > somewhere in the middle. > ... Are you seriously proposing optimizing specs for readers who read quickly and skip over details? What makes you think that if stuff gets repeated this type of reader will get it? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 2 03:51:50 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20878 for ; Thu, 2 Dec 2004 03:51:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZmgF-0004XC-ES for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 08:51:15 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZmgF-0004WZ-1O for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 08:51:15 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZmg8-0001Kp-1Q for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 08:51:08 +0000 Received: (qmail 21360 invoked by uid 65534); 2 Dec 2004 08:50:42 -0000 Received: from pD9E51B50.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.27.80) by mail.gmx.net (mp026) with SMTP; 02 Dec 2004 09:50:42 +0100 X-Authenticated: #1915285 Message-ID: <41AED75D.1050409@gmx.de> Date: Thu, 02 Dec 2004 09:50:37 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: ejw@cs.ucsc.edu, "'WebDAV (WebDAV WG)'" References: <200412012018.iB1KIHxs022402@cats-mx3.ucsc.edu> <84AD3812-4401-11D9-9DD0-000A95B2BB72@osafoundation.org> In-Reply-To: <84AD3812-4401-11D9-9DD0-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AED75D.1050409@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9060 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 08:51:15 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >> Yes, that's correct. I'm fine with this being added as an action item for >> 2518bis as well. >> >> > Sounds good... getting such an example into RFC sooner as well as later > makes sense to me. Actually, and with all due respect, to me this seems to be lame. Are we supposed to put examples that having nothing whatsover to do with BIND per se into the BIND spec just because it happens to be the next spec that's supposed to get finished? I fear that is an open-ended set of possible clarifications, and doing all of them certainly is not the right way to finish the spec. Speaking of which, what is the status of RFC2518bis? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 2 07:09:23 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06538 for ; Thu, 2 Dec 2004 07:09:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZpkp-0000vD-KM for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 12:08:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZpko-0000ue-CJ for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 12:08:10 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZpkh-0003mY-AA for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 12:08:03 +0000 Received: (qmail 30191 invoked by uid 65534); 2 Dec 2004 12:07:37 -0000 Received: from p50824674.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.70.116) by mail.gmx.net (mp025) with SMTP; 02 Dec 2004 13:07:37 +0100 X-Authenticated: #1915285 Message-ID: <41AF0588.1050608@gmx.de> Date: Thu, 02 Dec 2004 13:07:36 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'WebDAV (WebDAV WG)'" CC: Geoffrey M Clemm References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AF0588.1050608@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9061 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 12:08:11 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > Thanks, Jim! Here's a reformatting which should avoid the column wrap > problem. OK (and thanks!), added in . Note that I add to remove some vertical space because Geoff's reformatted version was too long for an RFC page.... :-) Which of the open issues below can be closed now? It seems to me that this example covers all of them, not just the first... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 2 09:01:07 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19191 for ; Thu, 2 Dec 2004 09:01:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZrUo-0007HL-Ek for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 13:59:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZrUm-0007G8-QB; Thu, 02 Dec 2004 13:59:44 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZrUf-0000fk-WD; Thu, 02 Dec 2004 13:59:38 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB2DxDNO030305; Thu, 2 Dec 2004 08:59:13 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB2DxD2t195442; Thu, 2 Dec 2004 08:59:13 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB2DxCru005678; Thu, 2 Dec 2004 08:59:13 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB2DxCrw005670; Thu, 2 Dec 2004 08:59:12 -0500 In-Reply-To: <41AED69F.9050200@gmx.de> To: Julian Reschke Cc: Lisa Dusseault , "'WebDAV (WebDAV WG)'" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 2 Dec 2004 08:59:14 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/02/2004 08:59:12, Serialize complete at 12/02/2004 08:59:12 Content-Type: multipart/alternative; boundary="=_alternative 004CD4A005256F5E_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Specification philosophies X-Archived-At: http://www.w3.org/mid/OF89E61F6F.F2E5CE76-ON85256F5E.004BA984-05256F5E.004CD4A3@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9062 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 13:59:46 +0000 This is a multipart message in MIME format. --=_alternative 004CD4A005256F5E_= Content-Type: text/plain; charset="US-ASCII" I share Julian's astonishment. Gratuitous repetition is a significant source of potential error for a careful reader, since after reading the same content for the third time, a careful reader will often be driven in frustration to skim over the repeated material, and risk missing some normative statement that happened to only appear somewhere in that third repetition. Given a choice of optimizing for the careful reader or optimizing for the skimmer, I find it hard to believe we would chose to optimize for the skimmer. The question of whether to include different forms of specification (i.e. text, pictures, examples) is very different. Here I agree that complementing text (which is essential and normative) with a few carefully selected pictures and examples is very desireable. I am sure everyone agrees with that. Cheers, Geoff Julian wrote on 12/02/2004 03:47:27 AM: > > Lisa Dusseault wrote: > > > ... > > short-term memory I have forgotten the details of what was already > > said. I also tend to read quickly and sometimes skip over details. > > Other readers fall along this range but I'm guessing Julian would be at > > nearly one extreme of fine memory/detail and me (I've always supposed) > > somewhere in the middle. > > ... > > Are you seriously proposing optimizing specs for readers who read > quickly and skip over details? What makes you think that if stuff gets > repeated this type of reader will get it? --=_alternative 004CD4A005256F5E_= Content-Type: text/html; charset="US-ASCII"
I share Julian's astonishment.

Gratuitous repetition is a significant source of potential
error for a careful reader, since after reading the same content for the
third time, a careful reader will often be driven in frustration to skim
over the repeated material, and risk missing some normative statement that
happened to only appear somewhere in that third repetition.

Given a choice of optimizing for the careful reader or optimizing for
the skimmer, I find it hard to believe we would chose to optimize for
the skimmer.

The question of whether to include different forms of specification
(i.e. text, pictures, examples) is very different.  Here I agree that
complementing text (which is essential and normative) with a few
carefully selected pictures and examples is very desireable.  I am
sure everyone agrees with that.

Cheers,
Geoff

Julian wrote on 12/02/2004 03:47:27 AM:
>
> Lisa Dusseault wrote:
>
> > ...
> > short-term memory I have forgotten the details of what was already
> > said.  I also tend to read quickly and sometimes skip over details.  
> > Other readers fall along this range but I'm guessing Julian would be at
> > nearly one extreme of fine memory/detail and me (I've always supposed)
> > somewhere in the middle.
> > ...
>
> Are you seriously proposing optimizing specs for readers who read
> quickly and skip over details? What makes you think that if stuff gets
> repeated this type of reader will get it?

 --=_alternative 004CD4A005256F5E_=-- From w3c-dist-auth-request@w3.org Thu Dec 2 09:02:32 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19330 for ; Thu, 2 Dec 2004 09:02:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZrWu-00089R-Gj for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 14:01:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZrWt-00088K-S0; Thu, 02 Dec 2004 14:01:55 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZrWn-0001P2-1o; Thu, 02 Dec 2004 14:01:49 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB2E1ORX017989; Thu, 2 Dec 2004 09:01:24 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB2E1O2t276628; Thu, 2 Dec 2004 09:01:24 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB2E1OSP008858; Thu, 2 Dec 2004 09:01:24 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB2E1OCf008850; Thu, 2 Dec 2004 09:01:24 -0500 In-Reply-To: <41AED75D.1050409@gmx.de> To: Julian Reschke Cc: ejw@cs.ucsc.edu, Lisa Dusseault , "'WebDAV (WebDAV WG)'" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 2 Dec 2004 09:01:26 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/02/2004 09:01:24, Serialize complete at 12/02/2004 09:01:24 Content-Type: multipart/alternative; boundary="=_alternative 004D081D85256F5E_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/OFD7F63AB6.BCA326FF-ON85256F5E.004CE761-85256F5E.004D081E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9063 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 14:01:56 +0000 This is a multipart message in MIME format. --=_alternative 004D081D85256F5E_= Content-Type: text/plain; charset="US-ASCII" I agree with Julian. The conclusion that I believe Jim, Julian, and I reached was that this material should appear in RFC2518bis, not that it should appear in both (for the reasons stated by Julian below). Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 12/02/2004 03:50:37 AM: > > Lisa Dusseault wrote: > > >> Yes, that's correct. I'm fine with this being added as an action item for > >> 2518bis as well. > >> > >> > > Sounds good... getting such an example into RFC sooner as well as later > > makes sense to me. > > Actually, and with all due respect, to me this seems to be lame. > > Are we supposed to put examples that having nothing whatsover to do with > BIND per se into the BIND spec just because it happens to be the next > spec that's supposed to get finished? I fear that is an open-ended set > of possible clarifications, and doing all of them certainly is not the > right way to finish the spec. > > Speaking of which, what is the status of RFC2518bis? > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 004D081D85256F5E_= Content-Type: text/html; charset="US-ASCII"
I agree with Julian.  The conclusion that I believe Jim, Julian, and I
reached was that this material should appear in RFC2518bis, not that it
should appear in both (for the reasons stated by Julian below).

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 12/02/2004 03:50:37 AM:

>
> Lisa Dusseault wrote:
>
> >> Yes, that's correct. I'm fine with this being added as an action item for
> >> 2518bis as well.
> >>
> >>
> > Sounds good... getting such an example into RFC sooner as well as later
> > makes sense to me.
>
> Actually, and with all due respect, to me this seems to be lame.
>
> Are we supposed to put examples that having nothing whatsover to do with
> BIND per se into the BIND spec just because it happens to be the next
> spec that's supposed to get finished? I fear that is an open-ended set
> of possible clarifications, and doing all of them certainly is not the
> right way to finish the spec.
>
> Speaking of which, what is the status of RFC2518bis?
>
> Best regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 004D081D85256F5E_=-- From w3c-dist-auth-request@w3.org Thu Dec 2 11:44:35 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07116 for ; Thu, 2 Dec 2004 11:44:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZu30-0000Lf-Ck for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 16:43:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZu2z-0000L5-0w for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 16:43:13 +0000 Received: from cats-mx4.ucsc.edu ([128.114.125.37]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZu2r-00055y-Ue for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 16:43:06 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx4.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB2Gg0fB001329 for ; Thu, 2 Dec 2004 08:42:03 -0800 (PST) Message-Id: <200412021642.iB2Gg0fB001329@cats-mx4.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Thu, 2 Dec 2004 08:41:53 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTYd0yJb+Gs0qQRR2mVaeckXvvkaAAFX40Q X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Specification philosophies X-Archived-At: http://www.w3.org/mid/200412021642.iB2Gg0fB001329@cats-mx4.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9064 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 16:43:14 +0000 Content-Transfer-Encoding: 7bit Seems to me the crux of the matter is your model of the reader of specifications. If your reader is very technically adept, detail-oriented, and a careful reader, then you'll want minimal repetition. If your reader is less technically skilled, and is more prone to deep reading of only portions of a specification, then repetition is good. Yaron was of the opinion that many implementers only ever read the examples (and he was never prone to hyperbole :-). - Jim From w3c-dist-auth-request@w3.org Thu Dec 2 12:07:06 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09413 for ; Thu, 2 Dec 2004 12:07:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZuPC-0001Pm-P0 for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 17:06:10 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZuPC-0001PI-Go for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 17:06:10 +0000 Received: from cats-mx2.ucsc.edu ([128.114.125.35]) by bart.w3.org with esmtp (Exim 4.34) id 1CZuPC-0000l4-8D for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 17:06:10 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx2.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB2H2igt021356 for ; Thu, 2 Dec 2004 09:02:47 -0800 (PST) Message-Id: <200412021702.iB2H2igt021356@cats-mx2.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Thu, 2 Dec 2004 09:02:38 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41AED75D.1050409@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTYTBhMRHXwKV14TomPC9tZLeCpLAAQwTPg X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412021702.iB2H2igt021356@cats-mx2.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9065 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 17:06:10 +0000 Content-Transfer-Encoding: 7bit Julian writes: > Are we supposed to put examples that having nothing whatsover > to do with BIND per se into the BIND spec just because it > happens to be the next spec that's supposed to get finished? > I fear that is an open-ended set of possible clarifications, > and doing all of them certainly is not the right way to > finish the spec. I think there should be examples of If header use in the BIND specification, and also in RFC 2518bis. Though quite related, this repetition is worthwhile. It is worthwhile in 2518bis because of the observed problems with client implementations of the If header. Interoperability errors are expensive to identify and fix, and tend to have negative impacts on users before they are fixed. Examples often help reduce interoperability errors, and are less costly to produce than it is to identify and fix an interoperability problem. The bind specification introduces some new wrinkles for If header passing and processing, especially the existence of loopback bindings. Additionally, a diligent, careful specification reader could still find it useful to have an example that confirms their understanding of how to apply the If header processing described in RFC 2518 to collections using bindings. For these two reasons it also makes sense to have an example of If header passing in the bind specification. - Jim From w3c-dist-auth-request@w3.org Thu Dec 2 12:08:35 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09557 for ; Thu, 2 Dec 2004 12:08:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZuR1-0002Qz-Bk for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 17:08:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZuR1-0002QT-5Z for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 17:08:03 +0000 Received: from cats-mx2.ucsc.edu ([128.114.125.35]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZuQu-0005zU-5V for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 17:07:56 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx2.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB2H5cmq022448 for ; Thu, 2 Dec 2004 09:05:41 -0800 (PST) Message-Id: <200412021705.iB2H5cmq022448@cats-mx2.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Thu, 2 Dec 2004 09:05:32 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41AED75D.1050409@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTYTBhMRHXwKV14TomPC9tZLeCpLAARLYKg X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Current status of 2518bis? X-Archived-At: http://www.w3.org/mid/200412021705.iB2H5cmq022448@cats-mx2.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9066 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 17:08:03 +0000 Content-Transfer-Encoding: 7bit > Speaking of which, what is the status of RFC2518bis? I'll pile on here, and second Julian's question. Who currently has the edit token for 2518bis, and when have they committed to producing a new specification draft? - Jim From w3c-dist-auth-request@w3.org Thu Dec 2 12:11:26 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10128 for ; Thu, 2 Dec 2004 12:11:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZuTn-0003c5-FW for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 17:10:55 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZuTn-0003bG-2X; Thu, 02 Dec 2004 17:10:55 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by bart.w3.org with esmtp (Exim 4.34) id 1CZuTm-0001tm-Qp; Thu, 02 Dec 2004 17:10:54 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB2HANSp005517; Thu, 2 Dec 2004 12:10:23 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB2HANhV265888; Thu, 2 Dec 2004 12:10:23 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB2HANTw013667; Thu, 2 Dec 2004 12:10:23 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB2HAMZF013657; Thu, 2 Dec 2004 12:10:23 -0500 In-Reply-To: <200412021642.iB2Gg0fB001329@cats-mx4.ucsc.edu> To: Cc: "'WebDAV \(WebDAV WG\)'" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 2 Dec 2004 12:10:25 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/02/2004 12:10:22, Serialize complete at 12/02/2004 12:10:22 Content-Type: multipart/alternative; boundary="=_alternative 005E553B85256F5E_=" Received-SPF: none (bart.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Specification philosophies X-Archived-At: http://www.w3.org/mid/OFA656A40C.5B66A7CD-ON85256F5E.005E202E-85256F5E.005E553E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9067 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 17:10:55 +0000 This is a multipart message in MIME format. --=_alternative 005E553B85256F5E_= Content-Type: text/plain; charset="US-ASCII" Perhaps this explains why some of the 2518 semantics/syntax can only be inferred from the examples (:-). Cheers, Geoff Jim wrote on 12/02/2004 11:41:53 AM: > Seems to me the crux of the matter is your model of the reader of > specifications. If your reader is very technically adept, detail-oriented, > and a careful reader, then you'll want minimal repetition. If your reader is > less technically skilled, and is more prone to deep reading of only portions > of a specification, then repetition is good. Yaron was of the opinion that > many implementers only ever read the examples (and he was never prone to > hyperbole :-). --=_alternative 005E553B85256F5E_= Content-Type: text/html; charset="US-ASCII"
Perhaps this explains why some of the 2518 semantics/syntax
can only be inferred from the examples (:-).

Cheers,
Geoff

Jim wrote on 12/02/2004 11:41:53 AM:

> Seems to me the crux of the matter is your model of the reader of
> specifications. If your reader is very technically adept, detail-oriented,
> and a careful reader, then you'll want minimal repetition. If your reader is
> less technically skilled, and is more prone to deep reading of only portions
> of a specification, then repetition is good. Yaron was of the opinion that
> many implementers only ever read the examples (and he was never prone to
> hyperbole :-).
 --=_alternative 005E553B85256F5E_=-- From w3c-dist-auth-request@w3.org Thu Dec 2 12:18:18 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10685 for ; Thu, 2 Dec 2004 12:18:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZuaD-0005e1-UH for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 17:17:33 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZuaD-0005dR-Nd for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 17:17:33 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CZuaD-0003tK-BS for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 17:17:33 +0000 Received: (qmail 20331 invoked by uid 65534); 2 Dec 2004 17:17:01 -0000 Received: from p50824622.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.70.34) by mail.gmx.net (mp025) with SMTP; 02 Dec 2004 18:17:01 +0100 X-Authenticated: #1915285 Message-ID: <41AF4E06.2090707@gmx.de> Date: Thu, 02 Dec 2004 18:16:54 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412021702.iB2H2igt021356@cats-mx2.ucsc.edu> In-Reply-To: <200412021702.iB2H2igt021356@cats-mx2.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AF4E06.2090707@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9068 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 17:17:33 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > I think there should be examples of If header use in the BIND specification, > and also in RFC 2518bis. Though quite related, this repetition is > worthwhile. It is worthwhile in 2518bis because of the observed problems > with client implementations of the If header. Interoperability errors are > expensive to identify and fix, and tend to have negative impacts on users > before they are fixed. Examples often help reduce interoperability errors, > and are less costly to produce than it is to identify and fix an > interoperability problem. > > The bind specification introduces some new wrinkles for If header passing > and processing, especially the existence of loopback bindings. Additionally, > a diligent, careful specification reader could still find it useful to have > an example that confirms their understanding of how to apply the If header > processing described in RFC 2518 to collections using bindings. For these > two reasons it also makes sense to have an example of If header passing in > the bind specification. As I said before, I'm not completely opposed to add examples; it's just that we should make sure we don't get carried away (because it's RFC2518bis, or, may I say, a separate locking spec's ([1]) role to add these). So, could you please specify exactly which situation you'd like the example to be for? My understanding was: - Method: REBIND - Locks on: source and target collection Correct? Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 2 12:43:09 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14174 for ; Thu, 2 Dec 2004 12:43:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZuyD-0006xS-DG for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 17:42:21 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZuyC-0006wy-Sa for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 17:42:20 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CZuyC-0004bf-Hs for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 17:42:20 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB2Hg2aa011274 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 2 Dec 2004 09:42:03 -0800 In-Reply-To: <41AED69F.9050200@gmx.de> References: <41AE2981.6060009@gmx.de> <8633B528-4402-11D9-9DD0-000A95B2BB72@osafoundation.org> <41AED69F.9050200@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <75B62D37-4489-11D9-9DD0-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: "'WebDAV (WebDAV WG)'" , Geoffrey M Clemm From: Lisa Dusseault Date: Thu, 2 Dec 2004 09:41:56 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Specification philosophies X-Archived-At: http://www.w3.org/mid/75B62D37-4489-11D9-9DD0-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9069 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 17:42:21 +0000 Content-Transfer-Encoding: 7bit I'm proposing optimizing the spec for the average reader who reads carefully (even when I read as carefully as I can, I do not remember every detail of the specification). I know that the reader eventually gets it when a spec is well-written because of experience, both with myself and with others, with well-written specs and badly-written specs. Besides, I've never advocated simple repetition. Mostly we've been talking about making requirements explicit, rather than have them "fall out" of the model. That's more than just repetition, it's more even than rephrasing -- it helps people with poor memories but also people who have different conscious or unconscious assumptions when they read the model description. Lisa On Dec 2, 2004, at 12:47 AM, Julian Reschke wrote: > Lisa Dusseault wrote: > >> ... >> short-term memory I have forgotten the details of what was already >> said. I also tend to read quickly and sometimes skip over details. >> Other readers fall along this range but I'm guessing Julian would be >> at nearly one extreme of fine memory/detail and me (I've always >> supposed) somewhere in the middle. >> ... > > Are you seriously proposing optimizing specs for readers who read > quickly and skip over details? What makes you think that if stuff gets > repeated this type of reader will get it? > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 2 12:47:38 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14647 for ; Thu, 2 Dec 2004 12:47:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZv2Z-0000Ry-5D for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 17:46:51 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZv2Y-0000RS-U5; Thu, 02 Dec 2004 17:46:50 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CZv2Y-0006FM-MH; Thu, 02 Dec 2004 17:46:50 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth-request@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB2HkRaa011444 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 2 Dec 2004 09:46:28 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13CFB5F8-448A-11D9-9DD0-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "'WebDAV (WebDAV WG)'" , w3c-dist-auth-request@w3.org From: Lisa Dusseault Date: Thu, 2 Dec 2004 09:46:21 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Specification philosophies X-Archived-At: http://www.w3.org/mid/13CFB5F8-448A-11D9-9DD0-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9070 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 17:46:51 +0000 Content-Transfer-Encoding: 7bit If you are truly astonished, it must be because you have not carefully been reading my previous emails and remembering the details. Perhaps you have been skimming them? I have never advocated gratuitous repetition or optimizing for the least careful reader. I have been advocating making requirements explicit, rather than leaving them to be deduced; and I have been advocating more examples, and I have pointed out that complementing text helps skimming readers as well as careful readers with different backgrounds and assumptions. Lisa On Dec 2, 2004, at 5:59 AM, Geoffrey M Clemm wrote: > I share Julian's astonishment. > > Gratuitous repetition is a significant source of potential > error for a careful reader, since after reading the same content for > the > third time, a careful reader will often be driven in frustration to > skim > over the repeated material, and risk missing some normative statement > that > happened to only appear somewhere in that third repetition. > > Given a choice of optimizing for the careful reader or optimizing for > the skimmer, I find it hard to believe we would chose to optimize for > the skimmer. > > The question of whether to include different forms of specification > (i.e. text, pictures, examples) is very different. Here I agree that > complementing text (which is essential and normative) with a few > carefully selected pictures and examples is very desireable. I am > sure everyone agrees with that. > > Cheers, > Geoff > > Julian wrote on 12/02/2004 03:47:27 AM: >> >> Lisa Dusseault wrote: >> >>> ... >>> short-term memory I have forgotten the details of what was already >>> said. I also tend to read quickly and sometimes skip over details. >>> Other readers fall along this range but I'm guessing Julian would be > at >>> nearly one extreme of fine memory/detail and me (I've always >>> supposed) > >>> somewhere in the middle. >>> ... >> >> Are you seriously proposing optimizing specs for readers who read >> quickly and skip over details? What makes you think that if stuff gets >> repeated this type of reader will get it? > From w3c-dist-auth-request@w3.org Thu Dec 2 12:52:33 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15155 for ; Thu, 2 Dec 2004 12:52:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZv7N-0002As-P5 for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 17:51:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZv7N-0002AO-Hy for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 17:51:49 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZv7G-0001Zr-KV for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 17:51:42 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB2Hpdaa011760 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 2 Dec 2004 09:51:40 -0800 In-Reply-To: <200412021705.iB2H5cmq022448@cats-mx2.ucsc.edu> References: <200412021705.iB2H5cmq022448@cats-mx2.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'WebDAV \(WebDAV WG\)'" From: Lisa Dusseault Date: Thu, 2 Dec 2004 09:51:33 -0800 To: X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Current status of 2518bis? X-Archived-At: http://www.w3.org/mid/CDCD810E-448A-11D9-9DD0-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9071 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 17:51:49 +0000 Content-Transfer-Encoding: 7bit I have the edit token. I have been unable to produce a new draft for a while because of unresolved issues. Now that we've got issue tracking up, we can either continue focusing on bindings and finish it, or split our focus. lisa On Dec 2, 2004, at 9:05 AM, Jim Whitehead wrote: > > >> Speaking of which, what is the status of RFC2518bis? > > I'll pile on here, and second Julian's question. Who currently has the > edit > token for 2518bis, and when have they committed to producing a new > specification draft? > > - Jim > > From w3c-dist-auth-request@w3.org Thu Dec 2 13:18:10 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16434 for ; Thu, 2 Dec 2004 13:18:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZvW7-00025S-F1 for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 18:17:23 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZvW7-00024s-8h for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 18:17:23 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by bart.w3.org with esmtp (Exim 4.34) id 1CZvW7-0000SV-1I for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 18:17:23 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB2IG8B8021039 for ; Thu, 2 Dec 2004 10:16:11 -0800 (PST) Message-Id: <200412021816.iB2IG8B8021039@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Thu, 2 Dec 2004 10:16:01 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41AF4E06.2090707@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTYktmNDcJ8wnceQZWdLGa5ptaKewAApcBg X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412021816.iB2IG8B8021039@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9072 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 18:17:23 +0000 Content-Transfer-Encoding: 7bit > So, could you please specify exactly which situation you'd > like the example to be for? My understanding was: > > - Method: REBIND > - Locks on: source and target collection > > Correct? I'd like the example to be the following. Given the following collection hierarchy, the example should cover a REBIND of C3:(CollZ->C1) to C3:(CollZ->C2). +------------------+ | Root Collection | | bindings: | | CollW | +------------------+ | | | +-------------------------------+ | Collection C1 |<--------+ | bindings: | | | CollX CollY | | +-------------------------------+ | | | | | | (creates loop) | | | | +-----------------+ +------------------+ | | Collection C2 | | Collection C3 | | | LOCKED infinity | | LOCKED infinity | | | bindings: | | bindings: | | | {none} | | y.gif CollZ | | +-----------------+ +------------------+ | | | | | +------+ | +---------------------------+ | Resource R2 | | (lock inhereited from C3) | +---------------------------+ Note that it's fine with me if we don't discuss exactly how the lock state in the example came to be -- just take it as a given, and go from there. - Jim From w3c-dist-auth-request@w3.org Thu Dec 2 14:30:50 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20337 for ; Thu, 2 Dec 2004 14:30:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZwe2-0006nM-Oq for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 19:29:38 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZwe1-0006ms-8O for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 19:29:37 +0000 Received: from cats-mx2.ucsc.edu ([128.114.125.35]) by bart.w3.org with esmtp (Exim 4.34) id 1CZwe1-0004j6-1G for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 19:29:37 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx2.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB2JRrCH022719 for ; Thu, 2 Dec 2004 11:27:56 -0800 (PST) Message-Id: <200412021927.iB2JRrCH022719@cats-mx2.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Thu, 2 Dec 2004 11:27:45 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41AF0588.1050608@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTYZ7HVDkpJuYENRSa/JJ++c4o49gANvwvA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412021927.iB2JRrCH022719@cats-mx2.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9073 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 19:29:38 +0000 Content-Transfer-Encoding: 7bit > Which of the open issues below can be closed now? > > t.html#rfc.issue.2.3_copy_depth_infinity> This can be closed. > t.html#rfc.issue.2.3_copy_vs_loops> This can be closed. > t.html#rfc.issue.2.3_copy_example> I'm still not 100% sure what cases this is intended to cover. My interpretation is that it covers (a) the target of a loopback binding, as well as (b) the case where there are multiple bindings to the same resource. We currently have an example for (a) and not (b). I'd like to see the following example added to address this shortcoming. Given the following collection hierarchy: +------------------+ | Root Collection | | bindings: | | CollX +------------------+ | | | +----------------+ | Collection C1 | | bindings: | | x.gif y.gif | +----------------+ | | | | +-------------+ | Resource R1 | +-------------+ A COPY of /CollX with Depth infinity to /CollY results in the following collection hierarchy: +------------------+ | Root Collection | | bindings: | | CollX CollY | +------------------+ | \ | \ | \ +----------------+ +-----------------+ | Collection C1 | | Collection C2 | | bindings: | | bindings: | | x.gif y.gif | | x.gif y.gif | +----------------+ +-----------------+ | | | | | | | | +-------------+ +-------------+ | Resource R1 | | Resource R2 | +-------------+ +-------------+ Assuming that those are the only two cases intended to be covered, the addition of this example would close this issue. - Jim From w3c-dist-auth-request@w3.org Thu Dec 2 15:11:15 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23442 for ; Thu, 2 Dec 2004 15:11:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZxHW-0003nw-QR for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 20:10:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZxHV-0003nN-Hl for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 20:10:25 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZxHO-0007Tf-EE for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 20:10:18 +0000 Received: (qmail 28468 invoked by uid 65534); 2 Dec 2004 20:09:52 -0000 Received: from pD9E51E07.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.7) by mail.gmx.net (mp026) with SMTP; 02 Dec 2004 21:09:52 +0100 X-Authenticated: #1915285 Message-ID: <41AF768C.5090301@gmx.de> Date: Thu, 02 Dec 2004 21:09:48 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412021927.iB2JRrCH022719@cats-mx2.ucsc.edu> In-Reply-To: <200412021927.iB2JRrCH022719@cats-mx2.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: BIND issue 2.3_copy_example, was: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AF768C.5090301@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9074 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 20:10:26 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: >>Which of the open issues below can be closed now? >> >>>t.html#rfc.issue.2.3_copy_depth_infinity> > > > This can be closed. > > >>>t.html#rfc.issue.2.3_copy_vs_loops> > > > This can be closed. Thanks, done ( updated accordingly). >>>t.html#rfc.issue.2.3_copy_example> > > > I'm still not 100% sure what cases this is intended to cover. My > interpretation is that it covers (a) the target of a loopback binding, as > well as (b) the case where there are multiple bindings to the same resource. > We currently have an example for (a) and not (b). > > I'd like to see the following example added to address this shortcoming. > > Given the following collection hierarchy: > > +------------------+ > | Root Collection | > | bindings: | > | CollX > +------------------+ > | > | > | > +----------------+ > | Collection C1 | > | bindings: | > | x.gif y.gif | > +----------------+ > | | > | | > +-------------+ > | Resource R1 | > +-------------+ > > A COPY of /CollX with Depth infinity to /CollY results in the following > collection hierarchy: > > +------------------+ > | Root Collection | > | bindings: | > | CollX CollY | > +------------------+ > | \ > | \ > | \ > +----------------+ +-----------------+ > | Collection C1 | | Collection C2 | > | bindings: | | bindings: | > | x.gif y.gif | | x.gif y.gif | > +----------------+ +-----------------+ > | | | | > | | | | > +-------------+ +-------------+ > | Resource R1 | | Resource R2 | > +-------------+ +-------------+ > > > Assuming that those are the only two cases intended to be covered, the > addition of this example would close this issue. I do agree that this the other case the text covers, and that our example currently doesn't show it explicitly (it does show it somehow for the collection resource binding structure being re-created, but people may be be aware because this also illustrates the bind loop behaviour). Any objections to *not* adding a new example, but just adding a second binding to y.gif to the example in ? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 2 15:20:20 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24458 for ; Thu, 2 Dec 2004 15:20:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZxQU-0006wN-6G for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 20:19:42 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZxQR-0006vH-Ci for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 20:19:39 +0000 Received: from cats-mx1.ucsc.edu ([128.114.125.34]) by bart.w3.org with esmtp (Exim 4.34) id 1CZxQR-0002vP-5A for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 20:19:39 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx1.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB2KIW9T026919 for ; Thu, 2 Dec 2004 12:18:45 -0800 (PST) Message-Id: <200412022018.iB2KIW9T026919@cats-mx1.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Thu, 2 Dec 2004 12:18:25 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41AF768C.5090301@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTYquMj0AlBPR+XTqSK0ArLmRnKyAAANjcA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: BIND issue 2.3_copy_example, was: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412022018.iB2KIW9T026919@cats-mx1.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9075 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 20:19:42 +0000 Content-Transfer-Encoding: 7bit > Any objections to *not* adding a new example, but just adding > a second binding to y.gif to the example in > t.html#rfc.section.2.3.1>? I thought about this, and lean towards having the second example because (a) the first example is already complex (b) it has a separate example for each of the two cases being considered That said, I could live with a single example. - Jim From w3c-dist-auth-request@w3.org Thu Dec 2 15:41:05 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27892 for ; Thu, 2 Dec 2004 15:41:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZxk7-0005lt-Fy for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 20:39:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZxjz-0005k7-4u for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 20:39:51 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZxjs-0007Ki-31 for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 20:39:44 +0000 Received: (qmail 4515 invoked by uid 65534); 2 Dec 2004 20:39:19 -0000 Received: from pD9E51E07.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.7) by mail.gmx.net (mp022) with SMTP; 02 Dec 2004 21:39:19 +0100 X-Authenticated: #1915285 Message-ID: <41AF7D74.6000303@gmx.de> Date: Thu, 02 Dec 2004 21:39:16 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412022018.iB2KIW9T026919@cats-mx1.ucsc.edu> In-Reply-To: <200412022018.iB2KIW9T026919@cats-mx1.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND issue 2.3_copy_example, was: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AF7D74.6000303@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9076 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 20:39:59 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > >>Any objections to *not* adding a new example, but just adding >>a second binding to y.gif to the example in >>>t.html#rfc.section.2.3.1>? > > > I thought about this, and lean towards having the second example because > (a) the first example is already complex > (b) it has a separate example for each of the two cases being considered > > That said, I could live with a single example. Fair enough, I added it as second example, see . Note I also updated the section title for the previous example. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 2 16:04:40 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29408 for ; Thu, 2 Dec 2004 16:04:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZy6l-00063n-GH for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 21:03:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZy6k-00063F-Ne for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 21:03:22 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZy6d-00054x-NQ for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 21:03:15 +0000 Received: (qmail 13145 invoked by uid 65534); 2 Dec 2004 21:02:50 -0000 Received: from pD9E51E07.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.7) by mail.gmx.net (mp001) with SMTP; 02 Dec 2004 22:02:50 +0100 X-Authenticated: #1915285 Message-ID: <41AF82ED.3030208@gmx.de> Date: Thu, 02 Dec 2004 22:02:37 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412021816.iB2IG8B8021039@cats-mx3.ucsc.edu> In-Reply-To: <200412021816.iB2IG8B8021039@cats-mx3.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AF82ED.3030208@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9077 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 21:03:23 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > >>So, could you please specify exactly which situation you'd >>like the example to be for? My understanding was: >> >>- Method: REBIND >>- Locks on: source and target collection >> >>Correct? > > > I'd like the example to be the following. > > Given the following collection hierarchy, the example should cover a REBIND > of C3:(CollZ->C1) to C3:(CollZ->C2). > > +------------------+ > | Root Collection | > | bindings: | > | CollW | > +------------------+ > | > | > | > +-------------------------------+ > | Collection C1 |<--------+ > | bindings: | | > | CollX CollY | | > +-------------------------------+ | > | | | > | | (creates loop) | > | | | > +-----------------+ +------------------+ | > | Collection C2 | | Collection C3 | | > | LOCKED infinity | | LOCKED infinity | | > | bindings: | | bindings: | | > | {none} | | y.gif CollZ | | > +-----------------+ +------------------+ | > | | | > | +------+ > | > +---------------------------+ > | Resource R2 | > | (lock inhereited from C3) | > +---------------------------+ > > Note that it's fine with me if we don't discuss exactly how the lock state > in the example came to be -- just take it as a given, and go from there. Wow. Just to make sure, we're talking about MOVE /CollW/CollY/CollZ HTTP/1.1 Destination: /CollW/CollX Overwrite: T ? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 2 16:12:01 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29855 for ; Thu, 2 Dec 2004 16:12:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZyEV-0007vH-Us for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 21:11:23 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZyEV-0007ui-Kf for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 21:11:23 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CZyEV-0002H4-9r for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 21:11:23 +0000 Received: (qmail 10760 invoked by uid 65534); 2 Dec 2004 21:10:50 -0000 Received: from pD9E51E07.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.7) by mail.gmx.net (mp013) with SMTP; 02 Dec 2004 22:10:50 +0100 X-Authenticated: #1915285 Message-ID: <41AF84D7.6080102@gmx.de> Date: Thu, 02 Dec 2004 22:10:47 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'WebDAV (WebDAV WG)'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: BIND issue 6_rebind_intro broke REBIND X-Archived-At: http://www.w3.org/mid/41AF84D7.6080102@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9078 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 21:11:23 +0000 Content-Transfer-Encoding: 7bit Hi, with , I (we?) have broken the description of REBIND. It currently reads "The REBIND method removes a binding to a resource from the collection identified by the Request-URI, and adds a binding to that resource into another collection. The request body specifies the binding to be removed (segment) and the new binding to be created (href). It is effectively an atomic form of a MOVE request." while it should say: "The REBIND method removes a binding to a resource from a collection, and adds a binding to that resource into the collection identified by the Request-URI. The request body specifies the binding to be added (segment) and the old binding to be removed (href). It is effectively an atomic form of a MOVE request." Note that also the precondition names that we changed will need to revert back to their original form. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 2 16:25:11 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00738 for ; Thu, 2 Dec 2004 16:25:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZyRD-0002mg-Pn for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 21:24:31 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZyRD-0002mC-5f for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 21:24:31 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZyR6-00024X-6r for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 21:24:24 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB2LMWGf029641; Thu, 2 Dec 2004 13:22:35 -0800 (PST) Message-Id: <200412022122.iB2LMWGf029641@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Julian Reschke'" Cc: "'WebDAV \(WebDAV WG\)'" Date: Thu, 2 Dec 2004 13:22:24 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41AF82ED.3030208@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTYsklflH7DNZuqRY66XueGO6xptAAAMgNA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412022122.iB2LMWGf029641@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9079 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 21:24:31 +0000 Content-Transfer-Encoding: 7bit > Wow. > > Just to make sure, we're talking about > > MOVE /CollW/CollY/CollZ HTTP/1.1 > Destination: /CollW/CollX > Overwrite: T I was thinking it would be: REBIND /CollW/CollY/ HTTP/1.1 Host: www.example.com Content-Type: text/xml; charset=utf-8 Content-Length: xxx If: () If: () CollZ /CollW/CollX/ - Jim From w3c-dist-auth-request@w3.org Thu Dec 2 16:31:17 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01048 for ; Thu, 2 Dec 2004 16:31:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZyX7-0004pf-6m for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 21:30:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZyX6-0004pB-R2 for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 21:30:36 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZyWz-0003YJ-Q1 for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 21:30:30 +0000 Received: (qmail 8416 invoked by uid 65534); 2 Dec 2004 21:30:04 -0000 Received: from pD9E51E07.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.7) by mail.gmx.net (mp012) with SMTP; 02 Dec 2004 22:30:04 +0100 X-Authenticated: #1915285 Message-ID: <41AF8958.8000704@gmx.de> Date: Thu, 02 Dec 2004 22:30:00 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: ejw@cs.ucsc.edu, "'WebDAV (WebDAV WG)'" References: <200412021816.iB2IG8B8021039@cats-mx3.ucsc.edu> <41AF82ED.3030208@gmx.de> In-Reply-To: <41AF82ED.3030208@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AF8958.8000704@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9080 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 21:30:37 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Jim Whitehead wrote: > >> >>> So, could you please specify exactly which situation you'd like the >>> example to be for? My understanding was: >>> >>> - Method: REBIND >>> - Locks on: source and target collection >>> >>> Correct? >> >> >> >> I'd like the example to be the following. >> >> Given the following collection hierarchy, the example should cover a >> REBIND >> of C3:(CollZ->C1) to C3:(CollZ->C2). >> >> +------------------+ >> | Root Collection | >> | bindings: | >> | CollW | >> +------------------+ >> | >> | >> | >> +-------------------------------+ >> | Collection C1 |<--------+ >> | bindings: | | >> | CollX CollY | | >> +-------------------------------+ | >> | | | >> | | (creates loop) | >> | | | >> +-----------------+ +------------------+ | >> | Collection C2 | | Collection C3 | | >> | LOCKED infinity | | LOCKED infinity | | >> | bindings: | | bindings: | | >> | {none} | | y.gif CollZ | | >> +-----------------+ +------------------+ | >> | | | >> | +------+ >> | >> +---------------------------+ >> | Resource R2 | >> | (lock inhereited from C3) | >> +---------------------------+ >> >> Note that it's fine with me if we don't discuss exactly how the lock >> state >> in the example came to be -- just take it as a given, and go from there. > > > Wow. > > Just to make sure, we're talking about > > MOVE /CollW/CollY/CollZ HTTP/1.1 > Destination: /CollW/CollX > Overwrite: T > > ? > > Best regards, Julian OK, given the lock tokens L2 for C2 and L3 for C3, I'd say the REBIND request would be: REBIND /CollW HTTP/1.1 If: () () Overwrite: T CollX /CollW/CollY/CollZ Reason: we need to supply both lock tokens as we're removing a binding to C3 that is protected by the lock L3, and we're removing the target binding /CollW/CollY which is protected by the lock L2. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 2 16:47:25 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02459 for ; Thu, 2 Dec 2004 16:47:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZymL-0003Jm-IO for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 21:46:21 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZymK-0003JH-8i for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 21:46:20 +0000 Received: from cats-mx1.ucsc.edu ([128.114.125.34]) by bart.w3.org with esmtp (Exim 4.34) id 1CZymJ-0004jc-VI for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 21:46:20 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx1.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB2LjCbP015098; Thu, 2 Dec 2004 13:45:16 -0800 (PST) Message-Id: <200412022145.iB2LjCbP015098@cats-mx1.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Julian Reschke'" , "'WebDAV \(WebDAV WG\)'" Date: Thu, 2 Dec 2004 13:45:04 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41AF8958.8000704@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTYthdQ/cuiK/41Qny2YXjnfOmaxQAAPdrA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412022145.iB2LjCbP015098@cats-mx1.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9081 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 21:46:21 +0000 Content-Transfer-Encoding: 7bit > > REBIND /CollW HTTP/1.1 > If: () > () > Overwrite: T > > > CollX > /CollW/CollY/CollZ > > > Reason: we need to supply both lock tokens as we're removing > a binding > to C3 that is protected by the lock L3, and we're removing the target > binding /CollW/CollY which is protected by the lock L2. This doesn't sound right to me. I'd say that we're removing the binding C3:(CollZ->C1), and hence we need the lock token L3. We're then creating the binding C3:(CollZ->C2), which requires the lock tokens L3 and L2, since C3's state is being modified (hence L3), and C2 is the destination (hence L2). I'm pretty confident of all except the final statement. > we're removing the target > binding /CollW/CollY which is protected by the lock L2. Isn't binding /CollW/CollY/ -- that is, C1:(CollY->C3) -- covered by lock L3? - Jim From w3c-dist-auth-request@w3.org Thu Dec 2 17:28:57 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07252 for ; Thu, 2 Dec 2004 17:28:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZzQY-0000ox-0d for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Dec 2004 22:27:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZzQW-0000oM-MV for w3c-dist-auth@listhub.w3.org; Thu, 02 Dec 2004 22:27:52 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZzQP-00054q-Kg for w3c-dist-auth@w3.org; Thu, 02 Dec 2004 22:27:45 +0000 Received: (qmail 17563 invoked by uid 65534); 2 Dec 2004 22:27:20 -0000 Received: from pD9E51E07.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.7) by mail.gmx.net (mp018) with SMTP; 02 Dec 2004 23:27:20 +0100 X-Authenticated: #1915285 Message-ID: <41AF96C2.9020308@gmx.de> Date: Thu, 02 Dec 2004 23:27:14 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412022145.iB2LjCbP015098@cats-mx1.ucsc.edu> In-Reply-To: <200412022145.iB2LjCbP015098@cats-mx1.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AF96C2.9020308@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9082 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Dec 2004 22:27:54 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > > >>REBIND /CollW HTTP/1.1 >>If: () >> () >>Overwrite: T >> >> >> CollX >> /CollW/CollY/CollZ >> >> >>Reason: we need to supply both lock tokens as we're removing >>a binding >>to C3 that is protected by the lock L3, and we're removing the target >>binding /CollW/CollY which is protected by the lock L2. > > > This doesn't sound right to me. I'd say that we're removing the binding > C3:(CollZ->C1), and hence we need the lock token L3. We're then creating the > binding C3:(CollZ->C2), which requires the lock tokens L3 and L2, since C3's > state is being modified (hence L3), and C2 is the destination (hence L2). > I'm pretty confident of all except the final statement. I missed the bind loop... This causes L2 and L3 to protect overlapping sets of URIs, so they must be shared locks, correct? >>we're removing the target >>binding /CollW/CollY which is protected by the lock L2. > > > Isn't binding /CollW/CollY/ -- that is, C1:(CollY->C3) -- covered by lock > L3? I guess we should stick with diagrams until we agree on the operation we're performing...: Before: +------------------+ | Root Collection | | bindings: | | CollW | +------------------+ | | | +-------------------------------+ | Collection C1 |<--------+ | bindings: | | | CollX CollY | | +-------------------------------+ | | | | | | (creates loop) | | | | +-----------------+ +------------------+ | | Collection C2 | | Collection C3 | | | LOCKED infinity | | LOCKED infinity | | | bindings: | | bindings: | | | {none} | | y.gif CollZ | | +-----------------+ +------------------+ | | | | | +------+ | +---------------------------+ | Resource R2 | | (lock inhereited from C3) | +---------------------------+ After: +------------------+ | Root Collection | | bindings: | | CollW | +------------------+ | | | +-------------------------------+ | Collection C1 | | bindings: | | CollX CollY | +-------------------------------+ | ^ | +-+ | | +-----------------+ +------------------+ | Collection C2 | | Collection C3 | | | LOCKED infinity | | bindings: | | bindings: | | {none} | | y.gif | +-----------------+ +------------------+ | | | +---------------------------+ | Resource R2 | | (lock inhereited from C3) | +---------------------------+ So C2 doesn't have any bindings in scope anymore (and thus no lock), and C1's new binding CollX identifies C1 itself, creating a new bind loop. I have the nagging feeling that this wasn't what you intended to do :-) Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 2 19:44:57 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20363 for ; Thu, 2 Dec 2004 19:44:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca1Xt-0007ES-6n for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 00:43:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca1Xr-0007Dr-Oe for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 00:43:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1Ca1Xk-0005EU-PG for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 00:43:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB30hYbU002334; Thu, 2 Dec 2004 16:43:34 -0800 Date: Thu, 2 Dec 2004 16:43:34 -0800 Message-Id: <200412030043.iB30hYbU002334@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/200412030043.iB30hYbU002334@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9083 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 00:43:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From lisa@osafoundation.org 2004-12-02 16:43 ------- I don't consider this issue closed. We can't expect spec readers to deduce the questions based on reading several specs and intuiting all the details of the models that the spec writers had. I agree it's too bad RFC2518bis isn't done but even if it were there would still be work to be done in bindings to say what lockdiscovery looks like, and how UNLOCK must work. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Dec 2 19:45:35 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20572 for ; Thu, 2 Dec 2004 19:45:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca1ZI-000895-UY for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 00:45:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca1ZI-00087p-En for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 00:45:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1Ca1ZB-0005nQ-Bd for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 00:44:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB30j3Ia002355; Thu, 2 Dec 2004 16:45:03 -0800 Date: Thu, 2 Dec 2004 16:45:03 -0800 Message-Id: <200412030045.iB30j3Ia002355@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/200412030045.iB30j3Ia002355@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9084 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 00:45:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From lisa@osafoundation.org 2004-12-02 16:45 ------- Even if RFC2518 implies that all properties have the same values on all bindings to a resource, the bindings specificatino should make that an explicit requirement. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Dec 2 19:52:58 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21542 for ; Thu, 2 Dec 2004 19:52:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca1gL-0002iR-1J for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 00:52:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca1gK-0002hs-NB for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 00:52:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1Ca1gD-0007xY-OL for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 00:52:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB30qKcC002381; Thu, 2 Dec 2004 16:52:20 -0800 Date: Thu, 2 Dec 2004 16:52:20 -0800 Message-Id: <200412030052.iB30qKcC002381@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/200412030052.iB30qKcC002381@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9085 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 00:52:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From lisa@osafoundation.org 2004-12-02 16:52 ------- I forgot to mention that REBIND needs to have its applicable privileges stated as well as BIND and UNBIND. Some suggested language: XXX. Interoperability with WebDAV ACL The WebDAV ACL specification defines the "DAV:bind" and "DAV:unbind" privileges. The "DAV:bind" privilege is naturally required to successfully execute a BIND request. The "DAV:unbind" privilege is required to execute an UNBIND request. Both privileges are required for REBIND, unless the REBIND is actually being used to rename a resource within the same collection, in which case only "DAV:write" privilege on the rebound resource is required. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Dec 2 19:59:54 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22200 for ; Thu, 2 Dec 2004 19:59:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca1mu-0005uq-0T for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 00:59:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca1mt-0005uL-Le for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 00:59:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1Ca1mm-0001vB-LA for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 00:59:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB30x7LK002402; Thu, 2 Dec 2004 16:59:07 -0800 Date: Thu, 2 Dec 2004 16:59:07 -0800 Message-Id: <200412030059.iB30x7LK002402@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 5] Bindings and DeltaV aren't fully interspecified X-Archived-At: http://www.w3.org/mid/200412030059.iB30x7LK002402@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9086 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 00:59:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From lisa@osafoundation.org 2004-12-02 16:59 ------- Can a client replace a Working Resource with a binding to some existing resource? If so, what does that do when it does CHECKIN that working resource? can a client use BIND to create a binding to a workspace? Can a client use BIND to create a binding to an activity? etc. for each new resource type defined in RFC3253... MUST the server support each of these operations? When a property contains an href, and that href points to a resource with multiple bindings, "it doesn't matter which binding is reported by the server". Ok, fine -- so we need to state that the server could show any binding URL and the client MUST be able to handle that. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Dec 2 22:04:55 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01991 for ; Thu, 2 Dec 2004 22:04:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca3j0-0004es-1O for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 03:03:14 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca3iy-0004eC-Uu for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 03:03:12 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by bart.w3.org with esmtp (Exim 4.34) id 1Ca3iy-0006ko-Qb for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 03:03:12 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB332d6S016852 for ; Thu, 2 Dec 2004 22:02:39 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB332dhV275866 for ; Thu, 2 Dec 2004 22:02:39 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB332d5g027268 for ; Thu, 2 Dec 2004 22:02:39 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB332doa027265 for ; Thu, 2 Dec 2004 22:02:39 -0500 In-Reply-To: <200412030059.iB30x7LK002402@ietf.cse.ucsc.edu> To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 2 Dec 2004 22:02:38 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/02/2004 22:02:39, Serialize complete at 12/02/2004 22:02:39 Content-Type: multipart/alternative; boundary="=_alternative 0010B86585256F5F_=" Received-SPF: none (bart.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 5] Bindings and DeltaV aren't fully interspecified X-Archived-At: http://www.w3.org/mid/OF3FB8E618.93DF7278-ON85256F5F.001057EC-85256F5F.0010B867@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9087 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 03:03:14 +0000 This is a multipart message in MIME format. --=_alternative 0010B86585256F5F_= Content-Type: text/plain; charset="US-ASCII" So what is the process here? How does one ever close out a bug if the original author can just re-open it at will? In particular, I suggest that at a minimum, someone other than the original reporter of the bug be required to re-open it, to indicate that there is at least one other person that feels it is not resolved. Otherwise any individual can effectively block progress in any spec. Cheers, Geoff Lisa wrote on 12/02/2004 07:59:07 PM: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5 > > lisa@osafoundation.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|RESOLVED |REOPENED > Resolution|WORKSFORME | > > > > ------- Additional Comments From lisa@osafoundation.org 2004-12-02 > 16:59 ------- > Can a client replace a Working Resource with a binding to some existing > resource? If so, what does that do when it does CHECKIN that > working resource? > > can a client use BIND to create a binding to a workspace? Can a > client use BIND > to create a binding to an activity? etc. for each new resource typedefined in > RFC3253... MUST the server support each of these operations? > > When a property contains an href, and that href points to a resource with > multiple bindings, "it doesn't matter which binding is reported by > the server". > Ok, fine -- so we need to state that the server could show any > binding URL and > the client MUST be able to handle that. > > > > ------- You are receiving this mail because: ------- > You are the QA contact for the bug, or are watching the QA contact. > --=_alternative 0010B86585256F5F_= Content-Type: text/html; charset="US-ASCII"
So what is the process here?  How does one ever close out a bug if
the original author can just re-open it at will?

In particular, I suggest that at a minimum, someone other than the original
reporter of the bug be required to re-open it, to indicate that there is at
least one other person that feels it is not resolved.

Otherwise any individual can effectively block progress in any spec.

Cheers,
Geoff


Lisa wrote on 12/02/2004 07:59:07 PM:

>
> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5
>
> lisa@osafoundation.org changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|RESOLVED                    |REOPENED
>          Resolution|WORKSFORME                  |
>
>
>
> ------- Additional Comments From lisa@osafoundation.org  2004-12-02
> 16:59 -------
> Can a client replace a Working Resource with a binding to some existing
> resource?  If so, what does that do when it does CHECKIN that
> working resource?
>
> can a client use BIND to create a binding to a workspace?  Can a
> client use BIND
> to create a binding to an activity?  etc. for each new resource typedefined in
> RFC3253... MUST the server support each of these operations?
>
> When a property contains an href, and that href points to a resource with
> multiple bindings, "it doesn't matter which binding is reported by
> the server".
>  Ok, fine -- so we need to state that the server could show any
> binding URL and
> the client MUST be able to handle that.
>
>
>
> ------- You are receiving this mail because: -------
> You are the QA contact for the bug, or are watching the QA contact.
>
--=_alternative 0010B86585256F5F_=-- From w3c-dist-auth-request@w3.org Thu Dec 2 22:35:18 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04739 for ; Thu, 2 Dec 2004 22:35:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca4D2-00064Q-Ja for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 03:34:16 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca4D0-00063B-26; Fri, 03 Dec 2004 03:34:14 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by bart.w3.org with esmtp (Exim 4.34) id 1Ca4Cz-00082T-MZ; Fri, 03 Dec 2004 03:34:13 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB33XfRD003048; Thu, 2 Dec 2004 22:33:41 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB33XfhV275888; Thu, 2 Dec 2004 22:33:41 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB33XeUi009177; Thu, 2 Dec 2004 22:33:40 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB33XeKS009174; Thu, 2 Dec 2004 22:33:40 -0500 In-Reply-To: <41AF96C2.9020308@gmx.de> To: Julian Reschke Cc: ejw@cs.ucsc.edu, "'WebDAV (WebDAV WG)'" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 2 Dec 2004 22:33:40 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/02/2004 22:33:39, Serialize complete at 12/02/2004 22:33:39 Content-Type: multipart/alternative; boundary="=_alternative 00138FCD85256F5F_=" Received-SPF: none (bart.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/OFF0BB27E1.5FF320EF-ON85256F5F.00131FB9-85256F5F.00138FCE@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9088 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 03:34:16 +0000 This is a multipart message in MIME format. --=_alternative 00138FCD85256F5F_= Content-Type: text/plain; charset="US-ASCII" I'm not following this. What is lock L3 and what is lock L2? (the locks in the picture are not named). In any case, I suggest that the example be modified to have exclusive locks (as Julian indicates, this example must have shared locks which is not as commonly implemented). Cheers, Geoff Julian wrote on 12/02/2004 05:27:14 PM: > > Jim Whitehead wrote: > > > > > >>REBIND /CollW HTTP/1.1 > >>If: () > >> () > >>Overwrite: T > >> > >> > >> CollX > >> /CollW/CollY/CollZ > >> > >> > >>Reason: we need to supply both lock tokens as we're removing > >>a binding > >>to C3 that is protected by the lock L3, and we're removing the target > >>binding /CollW/CollY which is protected by the lock L2. > > > > > > This doesn't sound right to me. I'd say that we're removing the binding > > C3:(CollZ->C1), and hence we need the lock token L3. We're then creating the > > binding C3:(CollZ->C2), which requires the lock tokens L3 and L2, since C3's > > state is being modified (hence L3), and C2 is the destination (hence L2). > > I'm pretty confident of all except the final statement. > > I missed the bind loop... This causes L2 and L3 to protect overlapping > sets of URIs, so they must be shared locks, correct? > > > >>we're removing the target > >>binding /CollW/CollY which is protected by the lock L2. > > > > > > Isn't binding /CollW/CollY/ -- that is, C1:(CollY->C3) -- covered by lock > > L3? > > I guess we should stick with diagrams until we agree on the operation > we're performing...: > > Before: > > +------------------+ > | Root Collection | > | bindings: | > | CollW | > +------------------+ > | > | > | > +-------------------------------+ > | Collection C1 |<--------+ > | bindings: | | > | CollX CollY | | > +-------------------------------+ | > | | | > | | (creates loop) | > | | | > +-----------------+ +------------------+ | > | Collection C2 | | Collection C3 | | > | LOCKED infinity | | LOCKED infinity | | > | bindings: | | bindings: | | > | {none} | | y.gif CollZ | | > +-----------------+ +------------------+ | > | | | > | +------+ > | > +---------------------------+ > | Resource R2 | > | (lock inhereited from C3) | > +---------------------------+ > > After: > > +------------------+ > | Root Collection | > | bindings: | > | CollW | > +------------------+ > | > | > | > +-------------------------------+ > | Collection C1 | > | bindings: | > | CollX CollY | > +-------------------------------+ > | ^ | > +-+ | > | > +-----------------+ +------------------+ > | Collection C2 | | Collection C3 | > | | LOCKED infinity | > | bindings: | | bindings: | > | {none} | | y.gif | > +-----------------+ +------------------+ > | > | > | > +---------------------------+ > | Resource R2 | > | (lock inhereited from C3) | > +---------------------------+ > > > So C2 doesn't have any bindings in scope anymore (and thus no lock), and > C1's new binding CollX identifies C1 itself, creating a new bind loop. > > I have the nagging feeling that this wasn't what you intended to do :-) > > Best regards, Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 00138FCD85256F5F_= Content-Type: text/html; charset="US-ASCII"
I'm not following this.  What is lock L3 and what is lock L2?
(the locks in the picture are not named).  In any case,
I suggest that the example be modified to have exclusive locks
(as Julian indicates, this example must have shared locks which
is not as commonly implemented).

Cheers,
Geoff

Julian wrote on 12/02/2004 05:27:14 PM:

>
> Jim Whitehead wrote:
> >  
> >
> >>REBIND /CollW HTTP/1.1
> >>If: <http://example.com/CollW/CollY/CollZ> (<L3>)
> >><http://example.com/CollW/CollX> (<L2>)
> >>Overwrite: T
> >>
> >><rebind xmlns="DAV:">
> >>   <segment>CollX</segment>
> >>   <href>/CollW/CollY/CollZ</href>
> >></rebind>
> >>
> >>Reason: we need to supply both lock tokens as we're removing
> >>a binding
> >>to C3 that is protected by the lock L3, and we're removing the target
> >>binding /CollW/CollY which is protected by the lock L2.
> >
> >
> > This doesn't sound right to me. I'd say that we're removing the binding
> > C3:(CollZ->C1), and hence we need the lock token L3. We're then creating the
> > binding C3:(CollZ->C2), which requires the lock tokens L3 and L2, since C3's
> > state is being modified (hence L3), and C2 is the destination (hence L2).
> > I'm pretty confident of all except the final statement.
>
> I missed the bind loop... This causes L2 and L3 to protect overlapping
> sets of URIs, so they must be shared locks, correct?
>
>
> >>we're removing the target
> >>binding /CollW/CollY which is protected by the lock L2.
> >
> >
> > Isn't binding /CollW/CollY/ -- that is, C1:(CollY->C3) -- covered by lock
> > L3?
>
> I guess we should stick with diagrams until we agree on the operation
> we're performing...:
>
> Before:
>
> +------------------+
> | Root Collection  |
> |  bindings:       |
> |  CollW           |
> +------------------+
>      |
>      |
>      |
> +-------------------------------+
> | Collection C1                 |<--------+
> | bindings:                     |         |
> | CollX               CollY     |         |
> +-------------------------------+         |
>      |                  |                  |
>      |                  |   (creates loop) |
>      |                  |                  |
> +-----------------+  +------------------+ |
> | Collection C2   |  | Collection C3    | |
> | LOCKED infinity |  | LOCKED infinity  | |
> | bindings:       |  | bindings:        | |
> |  {none}         |  | y.gif     CollZ  | |
> +-----------------+  +------------------+ |
>                        |            |      |
>                        |            +------+
>                        |
>                    +---------------------------+
>                    | Resource R2               |
>                    | (lock inhereited from C3) |
>                    +---------------------------+
>
> After:
>
> +------------------+
> | Root Collection  |
> |  bindings:       |
> |  CollW           |
> +------------------+
>      |
>      |
>      |
> +-------------------------------+
> | Collection C1                 |
> | bindings:                     |
> | CollX               CollY     |
> +-------------------------------+
>      | ^                |
>      +-+                |
>                         |
> +-----------------+  +------------------+
> | Collection C2   |  | Collection C3    |
> |                 | LOCKED infinity  |
> | bindings:       |  | bindings:        |
> |  {none}         |  | y.gif            |
> +-----------------+  +------------------+
>                        |
>                        |
>                        |
>                    +---------------------------+
>                    | Resource R2               |
>                    | (lock inhereited from C3) |
>                    +---------------------------+
>
>
> So C2 doesn't have any bindings in scope anymore (and thus no lock), and
> C1's new binding CollX identifies C1 itself, creating a new bind loop.
>
> I have the nagging feeling that this wasn't what you intended to do :-)
>
> Best regards, Julian
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 00138FCD85256F5F_=-- From w3c-dist-auth-request@w3.org Fri Dec 3 02:30:13 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05503 for ; Fri, 3 Dec 2004 02:30:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca7rT-0003TP-Nb for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 07:28:15 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca7rR-0003SE-8G for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 07:28:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1Ca7rK-0003Fa-95 for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 07:28:06 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB37SBnA002616; Thu, 2 Dec 2004 23:28:11 -0800 Date: Thu, 2 Dec 2004 23:28:11 -0800 Message-Id: <200412030728.iB37SBnA002616@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/200412030728.iB37SBnA002616@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9089 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 07:28:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-02 23:28 ------- Let's note that we disagree about this issue. - I have answered your specific questions based on the published (RFC2518) and to-be-published-spec (BIND). - And yes, we can expect that readers to indeed read both RFC2518 and BIND; if we don't the whole activitiy doesn't make sense at all. Please do not reopen this issue unless there are really new arguments. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 02:34:33 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05788 for ; Fri, 3 Dec 2004 02:34:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca7wt-0004ty-DU for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 07:33:51 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca7wt-0004tG-55 for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 07:33:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1Ca7ws-0005K6-UH for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 07:33:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB37XnWT002635; Thu, 2 Dec 2004 23:33:49 -0800 Date: Thu, 2 Dec 2004 23:33:49 -0800 Message-Id: <200412030733.iB37XnWT002635@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/200412030733.iB37XnWT002635@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9090 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 07:33:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-02 23:33 ------- I don't understand this statement. BIND needs to say that RFC2518 applies? The data model for BIND is described in Section 1 ("Introduction"), and as far as I can tell, it says exactly what it should say. As dicussed in , there seems to be rough consensus of all others particating in the discussion that there is no need for a change. If you disagree, please convince other active working group participants to speak up. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 02:36:07 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05890 for ; Fri, 3 Dec 2004 02:36:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca7yV-000630-RR for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 07:35:31 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca7yU-00062R-Nj for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 07:35:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1Ca7yN-00058n-L3 for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 07:35:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB37ZUwl002652; Thu, 2 Dec 2004 23:35:30 -0800 Date: Thu, 2 Dec 2004 23:35:30 -0800 Message-Id: <200412030735.iB37ZUwl002652@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/200412030735.iB37ZUwl002652@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9091 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 07:35:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-02 23:35 ------- REBIND is defined as being an atomic form of MOVE, so I don't see why it needs to be stated that the same permissions are required. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 02:45:00 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06432 for ; Fri, 3 Dec 2004 02:45:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca86y-00006Y-FK for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 07:44:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca86y-00005c-81 for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 07:44:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1Ca86r-00087w-7s for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 07:44:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB37iFIr002672; Thu, 2 Dec 2004 23:44:15 -0800 Date: Thu, 2 Dec 2004 23:44:15 -0800 Message-Id: <200412030744.iB37iFIr002672@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 5] Bindings and DeltaV aren't fully interspecified X-Archived-At: http://www.w3.org/mid/200412030744.iB37iFIr002672@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9092 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 07:44:16 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-02 23:44 ------- "Can a client replace a Working Resource with a binding to some existing resource? If so, what does that do when it does CHECKIN that working resource?" You can't replace resources with bindings. You can remove bindings, add bindings or overwrite bindings with other bindings. If you replace a binding to a WR by a binding to something else, the URI now identifies a different resource. It's impossible to say how that one behaves without knowing what it is. Please be more specific. "can a client use BIND to create a binding to a workspace? Can a client use BIND to create a binding to an activity? etc. for each new resource type defined in RFC3253... MUST the server support each of these operations?" I have no opinion on these, and I doubt that you can get RFC3253 implementers to agree on it. I'm not sure why this is relevant for BIND. If a server doesn't support additional bindings for a specific resource, a BIND request will fail. "When a property contains an href, and that href points to a resource with multiple bindings, "it doesn't matter which binding is reported by the server". Ok, fine -- so we need to state that the server could show any binding URL and the client MUST be able to handle that." That's a RFC3253 issue, not a BIND issue. See , issue 1.4.5_STABLE_HREF. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 03:14:08 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09483 for ; Fri, 3 Dec 2004 03:14:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca8Z1-00007R-L9 for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 08:13:15 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca8Yz-00005v-Sf for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 08:13:13 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1Ca8Yz-0000wl-JL for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 08:13:13 +0000 Received: from [192.168.1.26] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.1.R) with ESMTP id md50000065323.msg for ; Fri, 03 Dec 2004 09:12:51 +0100 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <13CFB5F8-448A-11D9-9DD0-000A95B2BB72@osafoundation.org> References: <13CFB5F8-448A-11D9-9DD0-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1F3EBB85-4503-11D9-BCC5-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit From: Stefan Eissing Date: Fri, 3 Dec 2004 09:12:49 +0100 To: "'WebDAV (WebDAV WG)'" X-Mailer: Apple Mail (2.619) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Fri, 03 Dec 2004 09:12:51 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Received-SPF: none (bart.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Specification philosophies X-Archived-At: http://www.w3.org/mid/1F3EBB85-4503-11D9-BCC5-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9093 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 08:13:15 +0000 Content-Transfer-Encoding: 7bit One has to admit, it was quite boring on the list during the last months (apart from the issue tracking system issue - that was a great one). I therefore welcome any fighting, disagreements, ironic comments, shallow arguments, evasion tactics, finger pointing and eye poking. //Stefan From w3c-dist-auth-request@w3.org Fri Dec 3 03:14:48 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09519 for ; Fri, 3 Dec 2004 03:14:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca8a0-0000sr-Q6 for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 08:14:16 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca8a0-0000rr-Fu for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 08:14:16 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1Ca8Zz-0001TE-R3 for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 08:14:16 +0000 Received: from [192.168.1.26] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.1.R) with ESMTP id md50000065325.msg for ; Fri, 03 Dec 2004 09:14:01 +0100 In-Reply-To: References: <200412021705.iB2H5cmq022448@cats-mx2.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <473A743D-4503-11D9-BCC5-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit Cc: , "'WebDAV \(WebDAV WG\)'" From: Stefan Eissing Date: Fri, 3 Dec 2004 09:13:56 +0100 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Fri, 03 Dec 2004 09:14:01 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Received-SPF: none (bart.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Current status of 2518bis? X-Archived-At: http://www.w3.org/mid/473A743D-4503-11D9-BCC5-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9094 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 08:14:16 +0000 Content-Transfer-Encoding: 7bit Lisa, please focus on 2518bis. //Stefan Am 02.12.2004 um 18:51 schrieb Lisa Dusseault: > > I have the edit token. I have been unable to produce a new draft for > a while because of unresolved issues. Now that we've got issue > tracking up, we can either continue focusing on bindings and finish > it, or split our focus. > > lisa > > On Dec 2, 2004, at 9:05 AM, Jim Whitehead wrote: > >> >> >>> Speaking of which, what is the status of RFC2518bis? >> >> I'll pile on here, and second Julian's question. Who currently has >> the edit >> token for 2518bis, and when have they committed to producing a new >> specification draft? >> >> - Jim >> >> > > From w3c-dist-auth-request@w3.org Fri Dec 3 03:17:48 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10009 for ; Fri, 3 Dec 2004 03:17:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca8cp-00027F-Bz for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 08:17:11 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca8cm-00026h-IK for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 08:17:08 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Ca8cm-0002e3-30 for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 08:17:08 +0000 Received: (qmail 29588 invoked by uid 65534); 3 Dec 2004 08:16:35 -0000 Received: from pD9E51E07.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.7) by mail.gmx.net (mp018) with SMTP; 03 Dec 2004 09:16:35 +0100 X-Authenticated: #1915285 Message-ID: <41B020DF.2030700@gmx.de> Date: Fri, 03 Dec 2004 09:16:31 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 5] Bindings and DeltaV aren't fully interspecified X-Archived-At: http://www.w3.org/mid/41B020DF.2030700@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9095 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 08:17:11 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > So what is the process here? How does one ever close out a bug if > the original author can just re-open it at will? I don't think there's a way to prevent it. > In particular, I suggest that at a minimum, someone other than the original > reporter of the bug be required to re-open it, to indicate that there is at > least one other person that feels it is not resolved. > > Otherwise any individual can effectively block progress in any spec. Not really. I don't consider the particular state of an issue entered on BugZilla of any relevance on the process, unless there is working group consensus that this is the case. Now *how* working group consensus is determined is an interesting question, and I hope that at some point of time (hopefully soon), Joe H. will tune in and discuss with us how he plans to proceed in general (and with BIND in particular). If we can't get the chair's attention (for whatever reason), we'll probably have to discuss alternative routes. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 3 03:19:40 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10232 for ; Fri, 3 Dec 2004 03:19:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca8ed-00030N-Bf for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 08:19:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca8ec-0002zT-R1 for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 08:19:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1Ca8eV-0001kA-Nx for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 08:18:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB38J12O002711; Fri, 3 Dec 2004 00:19:01 -0800 Date: Fri, 3 Dec 2004 00:19:01 -0800 Message-Id: <200412030819.iB38J12O002711@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/200412030819.iB38J12O002711@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9096 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 08:19:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-03 00:19 ------- That being said, I think the proposed text for REBIND is incorrect. See 's entry for MOVE. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 03:23:20 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10627 for ; Fri, 3 Dec 2004 03:23:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca8iC-0004Iw-VX for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 08:22:44 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca8iC-0004IH-K9 for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 08:22:44 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Ca8iB-0005Yu-Nu for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 08:22:44 +0000 Received: (qmail 19821 invoked by uid 65534); 3 Dec 2004 08:22:11 -0000 Received: from pD9E51E07.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.7) by mail.gmx.net (mp018) with SMTP; 03 Dec 2004 09:22:11 +0100 X-Authenticated: #1915285 Message-ID: <41B0222F.90008@gmx.de> Date: Fri, 03 Dec 2004 09:22:07 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: ejw@cs.ucsc.edu, "'WebDAV (WebDAV WG)'" , w3c-dist-auth-request@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: BIND issue 2.6_when_do_ids_change, was: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41B0222F.90008@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9097 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 08:22:44 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > Jim wrote on 12/01/2004 03:16:02 PM: > > > Geoff writes: > > I'm OK with adding this as the form of an example, i.e., in > section 2.6, > > after the sentence stating that new resources get new > resource-id's, we > > could say that "for example, when a new version resource is > created, it > > receives a new resource-id". > > > > That's fine with me, and let's mention VCRs while we're at it. > > Now that's a more interesting topic (:-). > > When you use the VERSION-CONTROL method with a specified Version, > one could interpret that as just restoring that resource, as opposed > to creating a new resource. I can imagine repository vendors having strong > (contradictory :-) opinions on that topic, so I'd suggest maintaining > a discrete silence on that topic for now (and if it needs to be resolved, > do so in the RFC-3253bis, and not in the binding specification). Checking ...: can I close the issue after making the editorial changes and replacing MOVE by REBIND? That is, do we need to mention MOVE here? If yes, any suggested text? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 3 03:31:35 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11724 for ; Fri, 3 Dec 2004 03:31:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ca8pk-0006od-8a for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 08:30:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Ca8pi-0006nN-6v for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 08:30:30 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1Ca8pb-0005GA-2Y for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 08:30:23 +0000 Received: (qmail 32440 invoked by uid 65534); 3 Dec 2004 08:29:57 -0000 Received: from pD9E51E07.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.30.7) by mail.gmx.net (mp007) with SMTP; 03 Dec 2004 09:29:57 +0100 X-Authenticated: #1915285 Message-ID: <41B023FC.70607@gmx.de> Date: Fri, 03 Dec 2004 09:29:48 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: ejw@cs.ucsc.edu, "'WebDAV (WebDAV WG)'" References: <200412011943.iB1JhW2B016123@cats-mx4.ucsc.edu> <41AE226C.8030404@gmx.de> In-Reply-To: <41AE226C.8030404@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND issue 3.2_example, was: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41B023FC.70607@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9098 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 08:30:32 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: >> Seems to me the href should hold a fully qualified URL, since other >> hrefs in >> the specification do this as well. > > > It may hold whatever RFC2518 defines for DAV:href (we probably should > let the DTD fragment refer to RFC2518, section 12.3, right?). RFC2518 > relies on RFC2068, section 3.2.1, which allows both absoluteURI and > relativeURI. > ... Do we need to clarify the source of DAV:href's definition somewhere in BIND? Alternatives seem to be: - explicitly mention it in the Terminology section, - add a comment to each DTD fragment using it. I personally feel that we don't need (for instance, RFC3744 doesn't seem to do it either), so unless somebody speaks up, I'll consider this one closed. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 3 12:37:03 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03098 for ; Fri, 3 Dec 2004 12:37:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaHJp-0004bp-SC for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 17:34:09 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CaHJo-0004bJ-CM for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 17:34:08 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by bart.w3.org with esmtp (Exim 4.34) id 1CaHJo-0003kv-4H for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 17:34:08 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB3HWPbV026871; Fri, 3 Dec 2004 09:32:29 -0800 (PST) Message-Id: <200412031732.iB3HWPbV026871@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Julian Reschke'" Cc: "'WebDAV \(WebDAV WG\)'" Date: Fri, 3 Dec 2004 09:32:19 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41B023FC.70607@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTZEkX810oQoX+gRYK3YL8klgrrCgASoQqw X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: BIND issue 3.2_example, was: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412031732.iB3HWPbV026871@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9099 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 17:34:09 +0000 Content-Transfer-Encoding: 7bit I think this issue can be closed for the BIND specification -- if it's to be pointed out clearly anywhere, it is in the 2518bis. - Jim > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, December 03, 2004 12:30 AM > To: Julian Reschke > Cc: ejw@cs.ucsc.edu; 'WebDAV (WebDAV WG)' > Subject: Re: BIND issue 3.2_example, was: Comments on bind-08 > > Julian Reschke wrote: > >> Seems to me the href should hold a fully qualified URL, > since other > >> hrefs in the specification do this as well. > > > > > > It may hold whatever RFC2518 defines for DAV:href (we > probably should > > let the DTD fragment refer to RFC2518, section 12.3, > right?). RFC2518 > > relies on RFC2068, section 3.2.1, which allows both absoluteURI and > > relativeURI. > > ... > > Do we need to clarify the source of DAV:href's definition > somewhere in > BIND? Alternatives seem to be: > > - explicitly mention it in the Terminology section, > > - add a comment to each DTD fragment using it. > > I personally feel that we don't need (for instance, RFC3744 > doesn't seem > to do it either), so unless somebody speaks up, I'll consider > this one > closed. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Fri Dec 3 13:12:26 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12171 for ; Fri, 3 Dec 2004 13:12:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaHtD-0001Zz-A6 for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 18:10:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaHtD-0001ZV-37 for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 18:10:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CaHt6-0001D0-2h for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 18:10:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB3IAf5B003261; Fri, 3 Dec 2004 10:10:41 -0800 Date: Fri, 3 Dec 2004 10:10:41 -0800 Message-Id: <200412031810.iB3IAf5B003261@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/200412031810.iB3IAf5B003261@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9101 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 18:10:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From ejw@cs.ucsc.edu 2004-12-03 10:10 ------- There is merit to both sides of this issue. Many lock interactions can be determined by a careful reading both 2518 and the BIND specification, and I agree these shouldn't be repeated in this specification. However, there are some new issues which the BIND specification raises that are not addressed or considered by 2518. These include: * The interactions of locks and loopback bindings. I'm pretty sure we don't want depth infinity locks to propagate along loopback bindings, since this could have unintended consequences (consider a loopback to the root collection). AFAIK, there is nothing in 2518 or BIND that addresses this situation, and the desired semantics (of ignorning the loopback binding) are not entirely consistent with a strict reading of 2518. A careful reader could have doubt concerning the right implementation approach in this case. * The effect on locks of creating a binding to a new (locked or unlocked) collection from within a currently depth infinity locked hierarchy. The semantics for MOVE in 2518 might be appropriate here, but there's still the ambiguity left over from the COPY, DELETE semantics, which are not the same as REBIND. Again, informed people could have legitimate differences of opinion on this issue, which is raised by the BIND specification's BIND and REBIND operators. Due to these two issues, I'm reopening this. I do note that this whole issue (where to address interactions of bindings and locks) is really symptomatic of DAV's containment model being spread across two specifications. I continue to believe that the best approach is to have BIND go to Proposed, and then merge it into 2518bis. Only when the containment model is in one place will we be able to be totally consistent about which examples to include, where to put which descriptions of semantics, etc. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 13:19:56 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14167 for ; Fri, 3 Dec 2004 13:19:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaI0a-0003Sm-2p for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 18:18:20 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CaI0Z-0003SD-Sb for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 18:18:19 +0000 Received: from cats-mx1.ucsc.edu ([128.114.125.34]) by bart.w3.org with esmtp (Exim 4.34) id 1CaI0Z-0000ZJ-Je for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 18:18:19 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx1.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB3IHTom022815 for ; Fri, 3 Dec 2004 10:17:32 -0800 (PST) Message-Id: <200412031817.iB3IHTom022815@cats-mx1.ucsc.edu> Reply-To: From: "Jim Whitehead" To: Date: Fri, 3 Dec 2004 10:17:22 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41B020DF.2030700@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTZEH/MdkKbqMqHRIGCjxCPQs/tOwAUxAGw X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 5] Bindings and DeltaV aren't fully interspecified X-Archived-At: http://www.w3.org/mid/200412031817.iB3IHTom022815@cats-mx1.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9102 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 18:18:20 +0000 Content-Transfer-Encoding: 7bit > > Otherwise any individual can effectively block progress in any spec. > > Not really. I don't consider the particular state of an issue > entered on BugZilla of any relevance on the process, unless > there is working group consensus that this is the case. Reopening an issue in Bugzilla indicates that there is not *exact* consensus on an issue. However, IETF rules only require *rough* consensus. While IETF rules only discuss entire specifications, and not individual issues, it does seem reasonable to use rough consensus as the yardstick for determining how to proceed on individual issues. One implication of this is that an individual cannot block progress on a specification in this way. That all said, I'll note that I just reopened the same issue, and even though there are several thousand kilometers separating me from Julian, I think I can still hear his cries of anguish :-) (FWIW, I do have technical concerns here, I didn't reopen just to be moot). - Jim From w3c-dist-auth-request@w3.org Fri Dec 3 13:25:25 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03099 for ; Fri, 3 Dec 2004 12:37:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaHJu-0004ci-Ez for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 17:34:14 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CaHJu-0004cE-8Y for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 17:34:14 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by bart.w3.org with esmtp (Exim 4.34) id 1CaHJu-0003lr-16 for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 17:34:14 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB3HWPbU026871; Fri, 3 Dec 2004 09:32:28 -0800 (PST) Message-Id: <200412031732.iB3HWPbU026871@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Julian Reschke'" Cc: "'WebDAV \(WebDAV WG\)'" Date: Fri, 3 Dec 2004 09:32:19 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41AF96C2.9020308@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTYvj15gVrLWWUARoivMkk9zwTkogAnrgwg X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200412031732.iB3HWPbU026871@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9100 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 17:34:14 +0000 Content-Transfer-Encoding: 7bit Julian writes: > I guess we should stick with diagrams until we agree on the operation > we're performing...: Yes, good point. Hmm, the figures you drew weren't quite right. Before (this is OK, I added lock token identifiers for clarity): +------------------+ | Root Collection | | bindings: | | CollW | +------------------+ | | | +-------------------------------+ | Collection C1 |<--------+ | bindings: | | | CollX CollY | | +-------------------------------+ | | | | | | (creates loop) | | | | +-----------------+ +------------------+ | | Collection C2 | | Collection C3 | | | LOCKED infinity | | LOCKED infinity | | | (lock token L2) | | (lock token L3) | | | bindings: | | bindings: | | | {none} | | y.gif CollZ | | +-----------------+ +------------------+ | | | | | +-----+ | +---------------------------+ | Resource R2 | | (lock inhereited from C3) | | (lock token L3) | +---------------------------+ After (this is changed -- CollZ now points to C2, not C1) +------------------+ | Root Collection | | bindings: | | CollW | +------------------+ | | | +-------------------------------+ | Collection C1 | | bindings: | | CollX CollY | +-------------------------------+ | | | | | | +-----------------+ +------------------+ | Collection C2 | | Collection C3 | | LOCKED infinity | | LOCKED infinity | | (lock token L2) | | (lock token L3) | | bindings: | | bindings: | | {none} | | CollZ y.gif | +-----------------+ +------------------+ ^ | | +----------------+ | | +---------------------------+ | Resource R2 | | (lock inhereited from C3) | | (lock token L3) | +---------------------------+ From w3c-dist-auth-request@w3.org Fri Dec 3 13:34:15 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16754 for ; Fri, 3 Dec 2004 13:34:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaIEM-0007ks-8y for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 18:32:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaIEM-0007kO-2c for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 18:32:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CaIEE-0000hs-TB for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 18:32:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB3IWWuo003288; Fri, 3 Dec 2004 10:32:32 -0800 Date: Fri, 3 Dec 2004 10:32:32 -0800 Message-Id: <200412031832.iB3IWWuo003288@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/200412031832.iB3IWWuo003288@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9103 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 18:32:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From ejw@cs.ucsc.edu 2004-12-03 10:32 ------- I agree with Lisa that the access control implications of REBIND should be made explicit. My suggestion is to add the following language to Section 6. Change: "It is effectively an atomic form of a MOVE request." To: "It is effectively an atomic form of a MOVE request, and MUST be treated as a MOVE for the purpose of determining access permissions (see RFC 3744, Appendix B)." ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 13:56:20 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20397 for ; Fri, 3 Dec 2004 13:56:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaIZF-0005bU-3u for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 18:54:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaIZE-0005au-TH for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 18:54:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CaIZ7-0008CG-RQ for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 18:54:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB3Is8RW003323; Fri, 3 Dec 2004 10:54:08 -0800 Date: Fri, 3 Dec 2004 10:54:08 -0800 Message-Id: <200412031854.iB3Is8RW003323@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/200412031854.iB3Is8RW003323@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9104 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 18:54:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-03 10:54 ------- I would like to avoid having a normative reference to RFC3744 within BIND. Any suggestions for text that would achieve that? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 13:58:30 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20664 for ; Fri, 3 Dec 2004 13:58:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaIc0-0006jp-Ds for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 18:57:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaIc0-0006jJ-58 for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 18:57:00 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by lisa.w3.org with esmtp (Exim 4.34) id 1CaIbs-0000zY-UX for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 18:56:53 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB3ItgWN013048 for ; Fri, 3 Dec 2004 10:55:45 -0800 (PST) Message-Id: <200412031855.iB3ItgWN013048@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: Date: Fri, 3 Dec 2004 10:55:35 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200412030733.iB37XnWT002635@ietf.cse.ucsc.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTZCnY/Pgk5rn71RH2XGsCD2OhpXgAWqCyQ X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/200412031855.iB3ItgWN013048@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9105 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 18:57:00 +0000 Content-Transfer-Encoding: 7bit I agree with closing this issue -- I think it's pretty clear that the dead properties should be the same, and the open-ended semantics of live properties are such that they could potentially vary by binding, if that's how theyr'e defined. - Jim From w3c-dist-auth-request@w3.org Fri Dec 3 13:59:22 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20772 for ; Fri, 3 Dec 2004 13:59:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaIco-0006w2-4H for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 18:57:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaIcn-0006vW-U0 for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 18:57:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CaIcg-0001GX-TQ for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 18:57:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB3IvnjP003343; Fri, 3 Dec 2004 10:57:49 -0800 Date: Fri, 3 Dec 2004 10:57:49 -0800 Message-Id: <200412031857.iB3IvnjP003343@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/200412031857.iB3IvnjP003343@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9106 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 18:57:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-03 10:57 ------- That's an interesting point. I do agree that if we need special treatment for locks in bind loops, we probably need to include them in BIND. However, I wasn't aware that there actually *is* a special treatment. This issue needs to be discussed before we make the next step. Regarding the other issue: again, I'm not sure what the issue is, and how it would be different from what we have in RFC2518. Please supply an example. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 14:14:29 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22920 for ; Fri, 3 Dec 2004 14:14:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaIrD-0003Wk-9d for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 19:12:43 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CaIrD-0003WG-2s for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 19:12:43 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CaIrC-0001jD-Np for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 19:12:43 +0000 Received: (qmail 32171 invoked by uid 65534); 3 Dec 2004 19:12:10 -0000 Received: from p5485659F.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.101.159) by mail.gmx.net (mp008) with SMTP; 03 Dec 2004 20:12:09 +0100 X-Authenticated: #1915285 Message-ID: <41B0BA86.7090300@gmx.de> Date: Fri, 03 Dec 2004 20:12:06 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412031732.iB3HWPbU026871@cats-mx3.ucsc.edu> In-Reply-To: <200412031732.iB3HWPbU026871@cats-mx3.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41B0BA86.7090300@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9107 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 19:12:43 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Julian writes: > > >>I guess we should stick with diagrams until we agree on the operation >>we're performing...: > > > Yes, good point. Hmm, the figures you drew weren't quite right. > > Before (this is OK, I added lock token identifiers for clarity): > > +------------------+ > | Root Collection | > | bindings: | > | CollW | > +------------------+ > | > | > | > +-------------------------------+ > | Collection C1 |<--------+ > | bindings: | | > | CollX CollY | | > +-------------------------------+ | > | | | > | | (creates loop) | > | | | > +-----------------+ +------------------+ | > | Collection C2 | | Collection C3 | | > | LOCKED infinity | | LOCKED infinity | | > | (lock token L2) | | (lock token L3) | | > | bindings: | | bindings: | | > | {none} | | y.gif CollZ | | > +-----------------+ +------------------+ | > | | | > | +-----+ > | > +---------------------------+ > | Resource R2 | > | (lock inhereited from C3) | > | (lock token L3) | > +---------------------------+ > > After (this is changed -- CollZ now points to C2, not C1) > > +------------------+ > | Root Collection | > | bindings: | > | CollW | > +------------------+ > | > | > | > +-------------------------------+ > | Collection C1 | > | bindings: | > | CollX CollY | > +-------------------------------+ > | | > | | > | | > +-----------------+ +------------------+ > | Collection C2 | | Collection C3 | > | LOCKED infinity | | LOCKED infinity | > | (lock token L2) | | (lock token L3) | > | bindings: | | bindings: | > | {none} | | CollZ y.gif | > +-----------------+ +------------------+ > ^ | | > +----------------+ | > | > +---------------------------+ > | Resource R2 | > | (lock inhereited from C3) | > | (lock token L3) | > +---------------------------+ I guess this explains the confusion. The operation that you're showing here keeps the binding name (CollZ), but changes the resource to which it refers (from C1 to C2). This is neither a MOVE nor a REBIND operation. You can express this as 1) UNBIND /collW/CollY/ CollZ followed by 2) BIND /collW/CollY/ CollZ /CollW/CollX The other obviously open question was whether bind loops need special treatment regarding depth:infinity locks. I wasn't under the impression they do. Is there a specific problem that needs to be solved? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 3 15:21:44 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02447 for ; Fri, 3 Dec 2004 15:21:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaJuo-0003VO-Ew for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 20:20:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaJum-0003Uo-T0 for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 20:20:28 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CaJuf-0001vr-SW for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 20:20:22 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB3KKHaa015184 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 3 Dec 2004 12:20:19 -0800 In-Reply-To: <200412031855.iB3ItgWN013048@cats-mx3.ucsc.edu> References: <200412031855.iB3ItgWN013048@cats-mx3.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Lisa Dusseault Date: Fri, 3 Dec 2004 12:20:09 -0800 To: X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/BAA4A728-4568-11D9-B70E-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9108 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 20:20:30 +0000 Content-Transfer-Encoding: 7bit There must not be agreement, because the last consensus on what was allowed was that even live properties would not be allowed to vary by binding. I'm happy with resolving the issue either way, however I believe the spec needs to make it very clear what servers MUST do. Lisa On Dec 3, 2004, at 10:55 AM, Jim Whitehead wrote: > > I agree with closing this issue -- I think it's pretty clear that the > dead > properties should be the same, and the open-ended semantics of live > properties are such that they could potentially vary by binding, if > that's > how theyr'e defined. > > - Jim > > From w3c-dist-auth-request@w3.org Fri Dec 3 15:23:45 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02583 for ; Fri, 3 Dec 2004 15:23:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaJxP-0004EV-8E for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 20:23:11 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CaJxO-0004Dq-Jy for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 20:23:10 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by bart.w3.org with esmtp (Exim 4.34) id 1CaJxO-0008Ne-Bz for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 20:23:10 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB3KM59J001700; Fri, 3 Dec 2004 12:22:09 -0800 (PST) Message-Id: <200412032022.iB3KM59J001700@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Julian Reschke'" Cc: "'WebDAV \(WebDAV WG\)'" Date: Fri, 3 Dec 2004 12:21:59 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41B0BA86.7090300@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTZa/4JyE9wPtDXTsGC7sCHJ0EA8gAAhmtw X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/200412032022.iB3KM59J001700@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9109 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 20:23:11 +0000 Content-Transfer-Encoding: 7bit > I guess this explains the confusion. The operation that > you're showing here keeps the binding name (CollZ), but > changes the resource to which it refers (from C1 to C2). This > is neither a MOVE nor a REBIND operation. > Ah! Thanks for figuring this out. So, REBIND really moves the head of the binding from one place to another. I was assuming it moved the tail from one place to another. I'll have to rethink the desired example. > The other obviously open question was whether bind loops need > special treatment regarding depth:infinity locks. I wasn't > under the impression they do. Is there a specific problem > that needs to be solved? Well, there are two issues. One is the handling of If headers for loopback bindings. The other is the semantics of the lock operation in the presence of loopback bindings. I think the handling of If headers is relatively straightforward. The semantics of locking are not. Consider the following collection hierarchy: +------------------+ | Root Collection | | bindings: |<---------------------+ | CollW | | +------------------+ | | | | | | | +-------------------------------+ | | Collection C1 | | | bindings: | | | CollX CollY | | +-------------------------------+ | | | | | | (creates loop) | | | | +-----------------+ +------------------+ | | Collection C2 | | Collection C3 | | | bindings: | | bindings: | | | {none} | | y.gif CollZ | | +-----------------+ +------------------+ | | | | | +-----+ | +---------------------------+ | Resource R2 | +---------------------------+ What is the outcome of an exclusive LOCK, depth infinity, submitted to /CollW/CollY/ ? Seems to me, the desired outcome is that only C3 and R2 are locked. However, if you read 2518, section 8.10.4 (Depth and Locking), it says: "If the Depth header is set to infinity then the resoruce specified in the Request-URI along with all its internal members, all the way down the hierarchy, are to be locked." In the binding specification, we define an Internal Member URI as "The URI that identifies an internal member of a collection, and that consists of the URI for the collection, followed by a slash character ('/'), followed by the path segment of the binding for that internal member." So, following these two definitions, one would interpret CollZ as an internal member URI, and then have the lock request apply to it, in this case locking the root collection, and all of its internal members, etc. What happens next is unclear. Either the lock fails (because /CollW/CollY/ is already locked), or the entire URL hierarchy on the server is added to the lock. In both cases, this seems like undesirable semantics. Lock really should ignore any loopback binding. While loopback bindings could theoretically have existed in the 2518 world, it really is only the introduction of the BIND specification that starts raising these issues with any urgency. - Jim From w3c-dist-auth-request@w3.org Fri Dec 3 15:25:39 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02856 for ; Fri, 3 Dec 2004 15:25:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaJzG-0005Ie-7C for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 20:25:06 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CaJzF-0005IA-PB for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 20:25:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CaJzF-0000aa-Gy for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 20:25:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB3KP4U9003418; Fri, 3 Dec 2004 12:25:04 -0800 Date: Fri, 3 Dec 2004 12:25:04 -0800 Message-Id: <200412032025.iB3KP4U9003418@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/200412032025.iB3KP4U9003418@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9110 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 20:25:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 ------- Additional Comments From lisa@osafoundation.org 2004-12-03 12:25 ------- How about simply text that begins with "If the server supports RFC3744 as well as this specification, then the server MUST meet the following requirements"? This is a normative reference to RFC3744, but since that's an RFC, I don't really see why we would object to a normative reference -- it won't delay bindings, and it doesn't need to be read by implementors unless they want to support it in which case they do have to read it :) The references to RFC3744 can be isolated in a section called "Compatibility with RFC3744", too, so it's not littering the rest of the spec. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 15:36:29 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04005 for ; Fri, 3 Dec 2004 15:36:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaK9Y-0007by-5w for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 20:35:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaK9V-0007bM-QJ for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 20:35:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CaK9O-00065n-OU for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 20:35:34 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB3KZeej003436; Fri, 3 Dec 2004 12:35:40 -0800 Date: Fri, 3 Dec 2004 12:35:40 -0800 Message-Id: <200412032035.iB3KZeej003436@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/200412032035.iB3KZeej003436@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9111 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 20:35:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-03 12:35 ------- The reason I'd like to avoid normative references to RFC3744 is that it seems quite possible that BIND (being a relative simple spec) advances earlier to the next standards level than RFC3744 (which is *really* complex). Which fits nicely into what you already said that the containment model used in BIND really should be part of core WebDAV. Can't we just simply say "It is effectively an atomic form of a MOVE request, and MUST be treated as a MOVE for the purpose of determining access permissions" and leave it at that? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 15:40:53 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04687 for ; Fri, 3 Dec 2004 15:40:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaKDy-0000hp-EW for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 20:40:18 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CaKDx-0000hG-Ub for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 20:40:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CaKDx-0003sq-Me for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 20:40:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB3KeH7b003455; Fri, 3 Dec 2004 12:40:17 -0800 Date: Fri, 3 Dec 2004 12:40:17 -0800 Message-Id: <200412032040.iB3KeH7b003455@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/200412032040.iB3KeH7b003455@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9112 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 20:40:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 ------- Additional Comments From ejw@cs.ucsc.edu 2004-12-03 12:40 ------- That language works for me. Hadn't thought about lockstep issues with specs advancing. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 15:44:21 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04856 for ; Fri, 3 Dec 2004 15:44:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaKHA-0001bC-Bj for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 20:43:36 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CaKH9-0001aa-9D for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 20:43:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CaKH8-0004dA-PU for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 20:43:34 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB3KhYMS003478; Fri, 3 Dec 2004 12:43:34 -0800 Date: Fri, 3 Dec 2004 12:43:34 -0800 Message-Id: <200412032043.iB3KhYMS003478@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/200412032043.iB3KhYMS003478@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9113 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 20:43:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 ------- Additional Comments From lisa@osafoundation.org 2004-12-03 12:43 ------- I don't think that having a normative reference to RFC3744 will be any impediment to having bindings to to Draft standard, even if RFC3744 were still at Proposed. So I'd prefer direct references which name which privileges apply to each method. However I don't object to the indirect references, which say something along the lines of "MUST be treated as for purposes of permissions". ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 15:45:53 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04939 for ; Fri, 3 Dec 2004 15:45:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaKIo-0002He-L3 for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 20:45:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaKIo-0002H5-6Q for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 20:45:18 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CaKIh-0008CS-2y for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 20:45:11 +0000 Received: (qmail 11653 invoked by uid 65534); 3 Dec 2004 20:44:45 -0000 Received: from p5485659F.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.101.159) by mail.gmx.net (mp011) with SMTP; 03 Dec 2004 21:44:45 +0100 X-Authenticated: #1915285 Message-ID: <41B0D039.4020009@gmx.de> Date: Fri, 03 Dec 2004 21:44:41 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412032022.iB3KM59J001700@cats-mx3.ucsc.edu> In-Reply-To: <200412032022.iB3KM59J001700@cats-mx3.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/41B0D039.4020009@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9114 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 20:45:18 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Ah! Thanks for figuring this out. So, REBIND really moves the head of the > binding from one place to another. I was assuming it moved the tail from one > place to another. > > I'll have to rethink the desired example. Great.... >>The other obviously open question was whether bind loops need >>special treatment regarding depth:infinity locks. I wasn't >>under the impression they do. Is there a specific problem >>that needs to be solved? > > > Well, there are two issues. One is the handling of If headers for loopback > bindings. The other is the semantics of the lock operation in the presence > of loopback bindings. I think the handling of If headers is relatively > straightforward. The semantics of locking are not. > > Consider the following collection hierarchy: > > +------------------+ > | Root Collection | > | bindings: |<---------------------+ > | CollW | | > +------------------+ | > | | > | | > | | > +-------------------------------+ | > | Collection C1 | | > | bindings: | | > | CollX CollY | | > +-------------------------------+ | > | | | > | | (creates loop) | > | | | > +-----------------+ +------------------+ | > | Collection C2 | | Collection C3 | | > | bindings: | | bindings: | | > | {none} | | y.gif CollZ | | > +-----------------+ +------------------+ | > | | | > | +-----+ > | > +---------------------------+ > | Resource R2 | > +---------------------------+ > > What is the outcome of an exclusive LOCK, depth infinity, submitted to > /CollW/CollY/ ? > > Seems to me, the desired outcome is that only C3 and R2 are locked. Well, I would expect the lock to behave as defined by RFC2518, effectively locking the whole namespace. > However, if you read 2518, section 8.10.4 (Depth and Locking), it says: > > "If the Depth header is set to infinity then the resoruce specified in the > Request-URI along with all its internal members, all the way down the > hierarchy, are to be locked." Why is that a problem? A bind loop that includes the namespace root seems like an edge case to me that doesn't require changing the base semantics. If it hurts to have a bind loop including the namespace root, don't do it. > In the binding specification, we define an Internal Member URI as > > "The URI that identifies an internal member of a collection, and that > consists of the URI for the collection, followed by a slash character ('/'), > followed by the path segment of the binding for that internal member." > > So, following these two definitions, one would interpret CollZ as an > internal member URI, and then have the lock request apply to it, in this > case locking the root collection, and all of its internal members, etc. What > happens next is unclear. Either the lock fails (because /CollW/CollY/ is > already locked), or the entire URL hierarchy on the server is added to the > lock. > > In both cases, this seems like undesirable semantics. Lock really should > ignore any loopback binding. While loopback bindings could theoretically > have existed in the 2518 world, it really is only the introduction of the > BIND specification that starts raising these issues with any urgency. Well, there are good reasons not to implement bind loops at all (this is why the spec explicitly allows servers to reject requests creating them, see DAV:cycle-allowed precondition for BIND). The presence of bind loops creates all kinds of issues, including those what to do with PROPFIND/depth:infinity and code that walks hierarchies and gets into infinite loops. I'm not surprised that Depth:infinity locks in bind loops are hard to handle, but IMHO that only means that one should avoid bind loops :-) I remember that Geoff was actually defending the ability to have bind loops, so maybe he can offer some opinion about how locks should behave. Personally, I'd say: "the way they are defined by RFC2518, and if this hurts, don't do it". Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 3 15:57:48 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05807 for ; Fri, 3 Dec 2004 15:57:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaKU9-0005jo-Ar for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 20:57:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaKU8-0005jK-TI for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 20:57:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CaKU1-0002k5-Rt for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 20:56:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB3Kv09k003496; Fri, 3 Dec 2004 12:57:00 -0800 Date: Fri, 3 Dec 2004 12:57:00 -0800 Message-Id: <200412032057.iB3Kv09k003496@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/200412032057.iB3Kv09k003496@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9115 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 20:57:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- URL|http://greenbytes.de/tech/we|http://greenbytes.de/tech/we |bdav/draft-ietf-webdav-bind-|bdav/draft-ietf-webdav-bind- |issues.html#bind_properties |latest.html#rfc.issue.6_rebi | |nd_premissions ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 15:59:01 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05996 for ; Fri, 3 Dec 2004 15:59:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaKVW-00063p-TQ for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 20:58:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaKVW-00063L-JL for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 20:58:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CaKVP-00037J-HB for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 20:58:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB3KwQ4h003511; Fri, 3 Dec 2004 12:58:26 -0800 Date: Fri, 3 Dec 2004 12:58:26 -0800 Message-Id: <200412032058.iB3KwQ4h003511@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/200412032058.iB3KwQ4h003511@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9116 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 20:58:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-03 12:58 ------- Intro to REBIND changed to: The REBIND method removes a binding to a resource from a collection, and adds a binding to that resource into the collection identified by the Request-URI. The request body specifies the binding to be added (segment) and the old binding to be removed (href). It is effectively an atomic form of a MOVE request, and MUST be treated the same way as MOVE for the purpose of determining access permissions. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 3 16:39:23 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08786 for ; Fri, 3 Dec 2004 16:39:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaL88-0004Ez-CV for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 21:38:20 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaL86-0004BP-Lx for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 21:38:18 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CaL7z-00054B-DU for w3c-dist-auth@w3c.org; Fri, 03 Dec 2004 21:38:11 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB3Lc8aa018132 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 3 Dec 2004 13:38:12 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200412032058.iB3KwQ0o003507@ietf.cse.ucsc.edu> References: <200412032058.iB3KwQ0o003507@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <99C3D88A-4573-11D9-B70E-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Fri, 3 Dec 2004 13:37:58 -0800 To: Webdav WG X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/99C3D88A-4573-11D9-B70E-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9117 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 21:38:20 +0000 Content-Transfer-Encoding: 7bit Great; what about BIND and UNBIND? lisa On Dec 3, 2004, at 12:58 PM, bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 > > julian.reschke@greenbytes.de changed: > > What |Removed |Added > ----------------------------------------------------------------------- > ----- > Status|REOPENED |RESOLVED > Resolution| |FIXED > > > > ------- Additional Comments From julian.reschke@greenbytes.de > 2004-12-03 12:58 ------- > Intro to REBIND changed to: > > The REBIND method removes a binding to a resource from a collection, > and adds a binding to that resource into the collection identified > by > the Request-URI. The request body specifies the binding to be added > (segment) and the old binding to be removed (href). It is > effectively an atomic form of a MOVE request, and MUST be treated > the same way as MOVE for the purpose of determining access > permissions. > > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. From w3c-dist-auth-request@w3.org Fri Dec 3 16:49:49 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09307 for ; Fri, 3 Dec 2004 16:49:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaLIY-0007il-Tw for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 21:49:06 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaLIW-0007hv-ME for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 21:49:04 +0000 Received: from cats-mx2.ucsc.edu ([128.114.125.35]) by lisa.w3.org with esmtp (Exim 4.34) id 1CaLIP-0007nx-Kq for w3c-dist-auth@w3c.org; Fri, 03 Dec 2004 21:48:57 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx2.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB3LmaQc027061 for ; Fri, 3 Dec 2004 13:48:43 -0800 (PST) Message-Id: <200412032148.iB3LmaQc027061@cats-mx2.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Webdav WG'" Date: Fri, 3 Dec 2004 13:48:29 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <99C3D88A-4573-11D9-B70E-000A95B2BB72@osafoundation.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTZgHs/hLs7F2gPR/OoVNl280hyNQAAUEWw X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/200412032148.iB3LmaQc027061@cats-mx2.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9118 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 21:49:06 +0000 Content-Transfer-Encoding: 7bit I think the fact that there are explicit bind and unbind privileges in the ACL protocol means that this doesn't need to be addressed in the bind specification. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Lisa Dusseault > Sent: Friday, December 03, 2004 1:38 PM > To: Webdav WG > Subject: Re: [Bug 4] Privilege interactions need to be > defined for BIND and UNBIND > > > Great; what about BIND and UNBIND? > > lisa > > On Dec 3, 2004, at 12:58 PM, bugzilla@soe.ucsc.edu wrote: > > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 > > > > julian.reschke@greenbytes.de changed: > > > > What |Removed |Added > > > ---------------------------------------------------------------------- > > - > > ----- > > Status|REOPENED |RESOLVED > > Resolution| |FIXED > > > > > > > > ------- Additional Comments From julian.reschke@greenbytes.de > > 2004-12-03 12:58 ------- > > Intro to REBIND changed to: > > > > The REBIND method removes a binding to a resource from a > collection, > > and adds a binding to that resource into the collection > identified > > by > > the Request-URI. The request body specifies the binding > to be added > > (segment) and the old binding to be removed (href). It is > > effectively an atomic form of a MOVE request, and MUST be treated > > the same way as MOVE for the purpose of determining access > > permissions. > > > > > > > > > > ------- You are receiving this mail because: ------- You > reported the > > bug, or are watching the reporter. > From w3c-dist-auth-request@w3.org Fri Dec 3 17:01:05 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10041 for ; Fri, 3 Dec 2004 17:01:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaLTS-0003yx-6W for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 22:00:22 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CaLTN-0003yE-Op for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 22:00:17 +0000 Received: from cats-mx4.ucsc.edu ([128.114.125.37]) by bart.w3.org with esmtp (Exim 4.34) id 1CaLTN-0000X4-GD for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 22:00:17 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx4.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB3Luups015575 for ; Fri, 3 Dec 2004 13:56:59 -0800 (PST) Message-Id: <200412032156.iB3Luups015575@cats-mx4.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Fri, 3 Dec 2004 13:56:48 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41B0D039.4020009@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTZeQKItFHfG8uCQXOB6JeQbT7P3AACNY8Q X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/200412032156.iB3Luups015575@cats-mx4.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9119 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 22:00:22 +0000 Content-Transfer-Encoding: 7bit > Why is that a problem? A bind loop that includes the > namespace root seems like an edge case to me that doesn't > require changing the base semantics. If it hurts to have a > bind loop including the namespace root, don't do it. The reason I think this is an issue is that I can't envision a scenario where you would ever want the lock to follow a loopback binding. That is, the reason it is a problem is the locks-follow-the-loopback-binding semantics are never what a client would want. You can make consistent semantics here, by saying that locks always propagate down a hierarchy, but never up. Yes, this is changing the base lock semantics somewhat, but in my opinion it doesn't violate the intent of 2518. This is essentially adapting the COPY depth infinity semantics for locks. > > In both cases, this seems like undesirable semantics. Lock really > > should ignore any loopback binding. While loopback bindings could > > theoretically have existed in the 2518 world, it really is only the > > introduction of the BIND specification that starts raising > these issues with any urgency. > > Well, there are good reasons not to implement bind loops at > all (this is why the spec explicitly allows servers to reject > requests creating them, see DAV:cycle-allowed precondition > for BIND). The presence of bind loops creates all kinds of > issues, including those what to do with > PROPFIND/depth:infinity and code that walks hierarchies and > gets into infinite loops. I'm not surprised that > Depth:infinity locks in bind loops are hard to handle, but > IMHO that only means that one should avoid bind loops :-) Saying "tut-tut" doesn't make the problems of the interactions of loopback bindings and depth locks go away. > Personally, I'd say: "the way they are defined by RFC2518, > and if this hurts, don't do it". We can be more nuanced than this. - Jim From w3c-dist-auth-request@w3.org Fri Dec 3 17:28:40 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12080 for ; Fri, 3 Dec 2004 17:28:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaLts-0003qk-Pc for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 22:27:40 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CaLts-0003nH-CN for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 22:27:40 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CaLto-0006hz-TV for w3c-dist-auth@w3.org; Fri, 03 Dec 2004 22:27:37 +0000 Received: (qmail 11735 invoked by uid 65534); 3 Dec 2004 22:27:00 -0000 Received: from p5485659F.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.101.159) by mail.gmx.net (mp018) with SMTP; 03 Dec 2004 23:27:00 +0100 X-Authenticated: #1915285 Message-ID: <41B0E830.6060804@gmx.de> Date: Fri, 03 Dec 2004 23:26:56 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412032156.iB3Luups015575@cats-mx4.ucsc.edu> In-Reply-To: <200412032156.iB3Luups015575@cats-mx4.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/41B0E830.6060804@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9120 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 22:27:40 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > The reason I think this is an issue is that I can't envision a scenario > where you would ever want the lock to follow a loopback binding. That is, > the reason it is a problem is the locks-follow-the-loopback-binding > semantics are never what a client would want. I'll not argue with that. But to me this means that if you don't want that, don't do it. The fact that depth:infinity locks have interestings results for bind loops doesn't necessarily mean that the base semantics need to be changed; not doing it if you don't want to certainly is an option as well (and a much simpler one spec-wise). > You can make consistent semantics here, by saying that locks always > propagate down a hierarchy, but never up. Yes, this is changing the base > lock semantics somewhat, but in my opinion it doesn't violate the intent of > 2518. This is essentially adapting the COPY depth infinity semantics for > locks. Sounds interesting; but as I'd like to hear feedback from those who actually see bind loops being used in practice. Geoff?? >>>In both cases, this seems like undesirable semantics. Lock really >>>should ignore any loopback binding. While loopback bindings could >>>theoretically have existed in the 2518 world, it really is only the >>>introduction of the BIND specification that starts raising >> >>these issues with any urgency. >> >>Well, there are good reasons not to implement bind loops at >>all (this is why the spec explicitly allows servers to reject >>requests creating them, see DAV:cycle-allowed precondition >>for BIND). The presence of bind loops creates all kinds of >>issues, including those what to do with >>PROPFIND/depth:infinity and code that walks hierarchies and >>gets into infinite loops. I'm not surprised that >>Depth:infinity locks in bind loops are hard to handle, but >>IMHO that only means that one should avoid bind loops :-) > > > Saying "tut-tut" doesn't make the problems of the interactions of loopback > bindings and depth locks go away. > >>Personally, I'd say: "the way they are defined by RFC2518, >>and if this hurts, don't do it". > > > We can be more nuanced than this. We *could*. The question is: do we want to complicate the spec for something that seems to be an edge case? As far as I am concerned, bind loops are something that most implementers won't implement anyway. Let's hear from those who actually want bind loops about what they think about how they should behave with locking. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 3 17:58:17 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16970 for ; Fri, 3 Dec 2004 17:58:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaMMP-000630-Bc for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Dec 2004 22:57:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaMMK-00061y-Je for w3c-dist-auth@listhub.w3.org; Fri, 03 Dec 2004 22:57:04 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CaMMD-0008I1-I7 for w3c-dist-auth@w3c.org; Fri, 03 Dec 2004 22:56:57 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3c.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB3Muuaa021459 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 3 Dec 2004 14:57:02 -0800 In-Reply-To: <200412032148.iB3LmaQc027061@cats-mx2.ucsc.edu> References: <200412032148.iB3LmaQc027061@cats-mx2.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9CCB57A0-457E-11D9-B70E-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: "'Webdav WG'" From: Lisa Dusseault Date: Fri, 3 Dec 2004 14:56:48 -0800 To: X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 4] Privilege interactions need to be defined for BIND and UNBIND X-Archived-At: http://www.w3.org/mid/9CCB57A0-457E-11D9-B70E-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9121 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Dec 2004 22:57:09 +0000 Content-Transfer-Encoding: 7bit I would prefer it to be explicit (my vote does not change) but I'll agree this issue can be closed with consensus against making it explicit. Lisa On Dec 3, 2004, at 1:48 PM, Jim Whitehead wrote: > > I think the fact that there are explicit bind and unbind privileges in > the > ACL protocol means that this doesn't need to be addressed in the bind > specification. > > - Jim > >> -----Original Message----- >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Lisa Dusseault >> Sent: Friday, December 03, 2004 1:38 PM >> To: Webdav WG >> Subject: Re: [Bug 4] Privilege interactions need to be >> defined for BIND and UNBIND >> >> >> Great; what about BIND and UNBIND? >> >> lisa >> >> On Dec 3, 2004, at 12:58 PM, bugzilla@soe.ucsc.edu wrote: >> >>> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=4 >>> >>> julian.reschke@greenbytes.de changed: >>> >>> What |Removed |Added >>> >> ---------------------------------------------------------------------- >>> - >>> ----- >>> Status|REOPENED |RESOLVED >>> Resolution| |FIXED >>> >>> >>> >>> ------- Additional Comments From julian.reschke@greenbytes.de >>> 2004-12-03 12:58 ------- >>> Intro to REBIND changed to: >>> >>> The REBIND method removes a binding to a resource from a >> collection, >>> and adds a binding to that resource into the collection >> identified >>> by >>> the Request-URI. The request body specifies the binding >> to be added >>> (segment) and the old binding to be removed (href). It is >>> effectively an atomic form of a MOVE request, and MUST be treated >>> the same way as MOVE for the purpose of determining access >>> permissions. >>> >>> >>> >>> >>> ------- You are receiving this mail because: ------- You >> reported the >>> bug, or are watching the reporter. >> > > From w3c-dist-auth-request@w3.org Sat Dec 4 05:55:53 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18974 for ; Sat, 4 Dec 2004 05:55:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CaXXn-00014s-7p for w3c-dist-auth-dist@listhub.w3.org; Sat, 04 Dec 2004 10:53:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CaXXm-00014J-Mi for w3c-dist-auth@listhub.w3.org; Sat, 04 Dec 2004 10:53:38 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CaXXf-0006iX-G9 for w3c-dist-auth@w3.org; Sat, 04 Dec 2004 10:53:31 +0000 Received: (qmail 12686 invoked by uid 65534); 4 Dec 2004 10:53:05 -0000 Received: from p5485659F.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.101.159) by mail.gmx.net (mp018) with SMTP; 04 Dec 2004 11:53:05 +0100 X-Authenticated: #1915285 Message-ID: <41B19703.7030201@gmx.de> Date: Sat, 04 Dec 2004 11:52:51 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: Joe Hildebrand References: <8D96EDA0AC04D31197B400A0C96C14800E2C69E8@corp.webb.net> <419648C7.3060507@gmx.de> <5F33B99E-3768-11D9-A37D-000A959A17A6@jabber.com> In-Reply-To: <5F33B99E-3768-11D9-A37D-000A959A17A6@jabber.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV at IETF 61 X-Archived-At: http://www.w3.org/mid/41B19703.7030201@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9122 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 04 Dec 2004 10:53:39 +0000 Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > > Not as I recall. Here's the agenda, as-built: > > - Agenda Bash > - Process > - Bugzilla issue tracking: > http://ietf.webdav.org:8080/bugzilla/ > - Closing issues > - BIND > - Redirect > - QUOTA > - CalDAV > - WebDAV events > (http://www.jabber.org/~stpeter/ietf/draft-hildebrand-webdav-notify > -00.html) > - PATCH > > We'll be sending in notes, soon. Philip, did you end up getting a dump > of the jabber room? I note that has neither the agenda nor meeting minutes listed... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Dec 5 21:41:38 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01355 for ; Sun, 5 Dec 2004 21:41:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cb8mc-0008Mr-Jn for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 02:39:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cb8mb-0008MG-3U for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 02:39:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cb8mT-0000ob-QB for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 02:39:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB62dNID017079; Sun, 5 Dec 2004 18:39:23 -0800 Date: Sun, 5 Dec 2004 18:39:23 -0800 Message-Id: <200412060239.iB62dNID017079@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/200412060239.iB62dNID017079@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9123 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 02:39:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2004-12-05 18:39 ------- Since RFC 2518 allows two URIs to map to the same resource, it is the responsibility of RFC-2518 to define the semantics of properties when accessed from different URIs that map to the same resource. The bindings draft will inherit whatever semantics is defined for this by 2518. If there is ambiguity in semantics introduced by 2518, it should be fixed in 2518bis, not in the bindings draft. Having one spec define the functionality of a feature defined by another spec is always a bad idea, since unless the two specs are evolved in lock step (which never happens), there will be periods of times when the two specs say conflicting things about that feature. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sun Dec 5 22:13:53 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03402 for ; Sun, 5 Dec 2004 22:13:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cb9JB-0001qX-19 for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 03:13:05 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cb9J9-0001pu-UN for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 03:13:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1Cb9J9-00036v-Kb for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 03:13:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB63D2qg017145; Sun, 5 Dec 2004 19:13:02 -0800 Date: Sun, 5 Dec 2004 19:13:02 -0800 Message-Id: <200412060313.iB63D2qg017145@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 70] New: REBIND arguments are like BIND X-Archived-At: http://www.w3.org/mid/200412060313.iB63D2qg017145@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9124 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 03:13:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=70 Summary: REBIND arguments are like BIND Product: WebDAV-BIND Version: -07 Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P1 Component: 06. REBIND Method AssignedTo: julian.reschke@greenbytes.de ReportedBy: geoffrey.clemm@us.ibm.com QAContact: w3c-dist-auth@w3.org The REBIND method was intended to have syntax that paralleled BIND. This means that the request-URL is the collection into which the binding is being created, the segment in the body is the new binding name in the request-URL collection, and the href in the body is the "source", i.e. the resource that is being rebound. The recent edits in this section (intended to address Jim's observation that the meaning of arguments of the method were not underspecified) were incorrect and broke this. In particular, the introductory sentences of REBIND should be modeled after BIND, and the precondition names (which were originally correct) should be restored. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sun Dec 5 22:19:27 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03827 for ; Sun, 5 Dec 2004 22:19:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cb9Of-0003Pp-Ry for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 03:18:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cb9Of-0003PC-3v for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 03:18:45 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cb9OX-0001fl-OR for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 03:18:37 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB63ICv5004539 for ; Sun, 5 Dec 2004 22:18:12 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB63ICV7285166 for ; Sun, 5 Dec 2004 22:18:12 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB63ICMs000568 for ; Sun, 5 Dec 2004 22:18:12 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB63ICjA000565 for ; Sun, 5 Dec 2004 22:18:12 -0500 In-Reply-To: <41B0BA86.7090300@gmx.de> To: "'WebDAV (WebDAV WG)'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Sun, 5 Dec 2004 22:18:15 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/05/2004 22:18:12, Serialize complete at 12/05/2004 22:18:12 Content-Type: multipart/alternative; boundary="=_alternative 0012262585256F62_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/OF324C2F5B.B1CD973F-ON85256F62.0011D04C-85256F62.00122626@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9125 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 03:18:45 +0000 This is a multipart message in MIME format. --=_alternative 0012262585256F62_= Content-Type: text/plain; charset="US-ASCII" The problem here is that Julian is using the intended marshalling of REBIND (which is like BIND, i.e. the request-URI identifies the collection into which the new binding will be created), while Jim is using the incorrectly updated definition in the current spec, which inverts the intended meaning (i.e. in the current draft, the syntax has been incorrectly "clarified" as having the request-URI identify the existing binding). I've submitted a bug on this. Cheers, Geoff Julian wrote on 12/03/2004 02:12:06 PM: > > Jim Whitehead wrote: > > Julian writes: > > > > > >>I guess we should stick with diagrams until we agree on the operation > >>we're performing...: > > > > > > Yes, good point. Hmm, the figures you drew weren't quite right. > > > > Before (this is OK, I added lock token identifiers for clarity): > > > > +------------------+ > > | Root Collection | > > | bindings: | > > | CollW | > > +------------------+ > > | > > | > > | > > +-------------------------------+ > > | Collection C1 |<--------+ > > | bindings: | | > > | CollX CollY | | > > +-------------------------------+ | > > | | | > > | | (creates loop) | > > | | | > > +-----------------+ +------------------+ | > > | Collection C2 | | Collection C3 | | > > | LOCKED infinity | | LOCKED infinity | | > > | (lock token L2) | | (lock token L3) | | > > | bindings: | | bindings: | | > > | {none} | | y.gif CollZ | | > > +-----------------+ +------------------+ | > > | | | > > | +-----+ > > | > > +---------------------------+ > > | Resource R2 | > > | (lock inhereited from C3) | > > | (lock token L3) | > > +---------------------------+ > > > > After (this is changed -- CollZ now points to C2, not C1) > > > > +------------------+ > > | Root Collection | > > | bindings: | > > | CollW | > > +------------------+ > > | > > | > > | > > +-------------------------------+ > > | Collection C1 | > > | bindings: | > > | CollX CollY | > > +-------------------------------+ > > | | > > | | > > | | > > +-----------------+ +------------------+ > > | Collection C2 | | Collection C3 | > > | LOCKED infinity | | LOCKED infinity | > > | (lock token L2) | | (lock token L3) | > > | bindings: | | bindings: | > > | {none} | | CollZ y.gif | > > +-----------------+ +------------------+ > > ^ | | > > +----------------+ | > > | > > +---------------------------+ > > | Resource R2 | > > | (lock inhereited from C3) | > > | (lock token L3) | > > +---------------------------+ > > I guess this explains the confusion. The operation that you're showing > here keeps the binding name (CollZ), but changes the resource to which > it refers (from C1 to C2). This is neither a MOVE nor a REBIND operation. > > You can express this as > > 1) UNBIND /collW/CollY/ > > CollZ > > > followed by > > 2) BIND /collW/CollY/ > > CollZ > /CollW/CollX > > > The other obviously open question was whether bind loops need special > treatment regarding depth:infinity locks. I wasn't under the impression > they do. Is there a specific problem that needs to be solved? > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 0012262585256F62_= Content-Type: text/html; charset="US-ASCII"
The problem here is that Julian is using the intended marshalling
of REBIND (which is like BIND, i.e. the request-URI identifies the
collection into which the new binding will be created), while Jim
is using the incorrectly updated definition in the current spec,
which inverts the intended meaning (i.e. in the current draft,
the syntax has been incorrectly "clarified" as having the request-URI
identify the existing binding).

I've submitted a bug on this.

Cheers,
Geoff

Julian wrote on 12/03/2004 02:12:06 PM:
>
> Jim Whitehead wrote:
> > Julian writes:
> >
> >
> >>I guess we should stick with diagrams until we agree on the operation
> >>we're performing...:
> >
> >
> > Yes, good point. Hmm, the figures you drew weren't quite right.
> >
> > Before (this is OK, I added lock token identifiers for clarity):
> >
> > +------------------+
> > | Root Collection  |
> > |  bindings:       |
> > |  CollW           |
> > +------------------+
> >      |
> >      |
> >      |
> > +-------------------------------+
> > | Collection C1                 |<--------+
> > | bindings:                     |         |
> > | CollX               CollY     |         |
> > +-------------------------------+         |
> >      |                  |                 |
> >      |                  |  (creates loop) |
> >      |                  |                 |
> > +-----------------+  +------------------+ |
> > | Collection C2   |  | Collection C3    | |
> > | LOCKED infinity |  | LOCKED infinity  | |
> > | (lock token L2) |  | (lock token L3)  | |
> > | bindings:       |  | bindings:        | |
> > |  {none}         |  | y.gif     CollZ  | |
> > +-----------------+  +------------------+ |
> >                        |            |     |
> >                        |            +-----+
> >                        |
> >                    +---------------------------+
> >                    | Resource R2               |
> >                    | (lock inhereited from C3) |
> >                    | (lock token L3)           |
> >                    +---------------------------+
> >
> > After (this is changed -- CollZ now points to C2, not C1)
> >
> > +------------------+
> > | Root Collection  |
> > |  bindings:       |
> > |  CollW           |
> > +------------------+
> >      |
> >      |
> >      |
> > +-------------------------------+
> > | Collection C1                 |
> > | bindings:                     |
> > | CollX               CollY     |
> > +-------------------------------+
> >      |                  |
> >      |                  |
> >      |                  |
> > +-----------------+  +------------------+
> > | Collection C2   |  | Collection C3    |
> > | LOCKED infinity |  | LOCKED infinity  |
> > | (lock token L2) |  | (lock token L3)  |
> > | bindings:       |  | bindings:        |
> > |  {none}         |  | CollZ     y.gif  |
> > +-----------------+  +------------------+
> >        ^                |           |
> >        +----------------+           |
> >                                     |
> >                    +---------------------------+
> >                    | Resource R2               |
> >                    | (lock inhereited from C3) |
> >                    | (lock token L3)           |
> >                    +---------------------------+
>
> I guess this explains the confusion. The operation that you're showing
> here keeps the binding name (CollZ), but changes the resource to which
> it refers (from C1 to C2). This is neither a MOVE nor a REBIND operation.
>
> You can express this as
>
> 1) UNBIND /collW/CollY/
>     <unbind xmlns="DAV:">
>       <segment>CollZ</segment>
>     </unbind>
>
> followed by
>
> 2) BIND /collW/CollY/
>     <bind xmlns="DAV:">
>       <segment>CollZ</segment>
>       <href>/CollW/CollX</href>
>     </bind>
>
> The other obviously open question was whether bind loops need special
> treatment regarding depth:infinity locks. I wasn't under the impression
> they do. Is there a specific problem that needs to be solved?
>
> Best regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 0012262585256F62_=-- From w3c-dist-auth-request@w3.org Sun Dec 5 22:28:21 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04244 for ; Sun, 5 Dec 2004 22:28:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cb9XG-0007GK-Fk for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 03:27:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cb9XB-0007FW-PJ for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 03:27:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cb9X4-0004Eb-J9 for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 03:27:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB63RX9d017169; Sun, 5 Dec 2004 19:27:33 -0800 Date: Sun, 5 Dec 2004 19:27:33 -0800 Message-Id: <200412060327.iB63RX9d017169@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 70] REBIND arguments should be like BIND X-Archived-At: http://www.w3.org/mid/200412060327.iB63RX9d017169@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9126 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 03:27:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=70 geoffrey.clemm@us.ibm.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|REBIND arguments are like |REBIND arguments should be |BIND |like BIND ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sun Dec 5 22:37:49 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04884 for ; Sun, 5 Dec 2004 22:37:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cb9gV-0001zd-PW for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 03:37:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cb9gV-0001yt-78 for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 03:37:11 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cb9gO-0006J0-3a for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 03:37:04 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB63adMm018280 for ; Sun, 5 Dec 2004 22:36:39 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB63adV7268154 for ; Sun, 5 Dec 2004 22:36:39 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB63adjG006920 for ; Sun, 5 Dec 2004 22:36:39 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB63adjc006915 for ; Sun, 5 Dec 2004 22:36:39 -0500 In-Reply-To: <200412032022.iB3KM59J001700@cats-mx3.ucsc.edu> To: "'WebDAV \(WebDAV WG\)'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Sun, 5 Dec 2004 22:36:42 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/05/2004 22:36:39, Serialize complete at 12/05/2004 22:36:39 Content-Type: multipart/alternative; boundary="=_alternative 0013D6B785256F62_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: REBIND example (was Re: Locks and loopback bindings) X-Archived-At: http://www.w3.org/mid/OF58388491.F4807275-ON85256F62.00122FD5-85256F62.0013D6B9@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9127 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 03:37:11 +0000 This is a multipart message in MIME format. --=_alternative 0013D6B785256F62_= Content-Type: text/plain; charset="US-ASCII" Jim wrote on 12/03/2004 03:21:59 PM: > > I guess this explains the confusion. The operation that > > you're showing here keeps the binding name (CollZ), but > > changes the resource to which it refers (from C1 to C2). This > > is neither a MOVE nor a REBIND operation. Actually, it is a REBIND operation, but in the opposite direction. > Ah! Thanks for figuring this out. So, REBIND really moves the head of the > binding from one place to another. I was assuming it moved the tail from one > place to another. Hmmm. That's an even more obscure way of saying it (:-). You were doing: BIND source-collection which is what the spec was incorrectly updated to say, while Julian was doing: BIND destination-collection which is what the spec originally was intended to say (to be like BIND). > I'll have to rethink the desired example. OK. Cheers, Geoff --=_alternative 0013D6B785256F62_= Content-Type: text/html; charset="US-ASCII"
Jim wrote on 12/03/2004 03:21:59 PM:

> > I guess this explains the confusion. The operation that
> > you're showing here keeps the binding name (CollZ), but
> > changes the resource to which it refers (from C1 to C2). This
> > is neither a MOVE nor a REBIND operation.

Actually, it is a REBIND operation, but in the opposite direction.

> Ah! Thanks for figuring this out. So, REBIND really moves the head of the
> binding from one place to another. I was assuming it moved the tail from one
> place to another.

Hmmm.  That's an even more obscure way of saying it (:-).

You were doing:
  BIND source-collection <source-segment, destination-URI>
which is what the spec was incorrectly updated to say, while Julian was doing:
  BIND destination-collection <destination-segment, source-URI>
which is what the spec originally was intended to say (to be like BIND).

> I'll have to rethink the desired example.

OK.  

Cheers,
Geoff
--=_alternative 0013D6B785256F62_=-- From w3c-dist-auth-request@w3.org Sun Dec 5 22:53:53 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06443 for ; Sun, 5 Dec 2004 22:53:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cb9vj-00080K-MV for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 03:52:55 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cb9vh-0007yo-NK for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 03:52:53 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by bart.w3.org with esmtp (Exim 4.34) id 1Cb9vh-0006kn-Hb for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 03:52:53 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB63qMBX007755 for ; Sun, 5 Dec 2004 22:52:22 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB63qMjD197768 for ; Sun, 5 Dec 2004 22:52:22 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB63qMQm019047 for ; Sun, 5 Dec 2004 22:52:22 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB63qMIQ019044 for ; Sun, 5 Dec 2004 22:52:22 -0500 In-Reply-To: <41B0D039.4020009@gmx.de> To: "'WebDAV (WebDAV WG)'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Sun, 5 Dec 2004 22:52:26 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/05/2004 22:52:21, Serialize complete at 12/05/2004 22:52:21 Content-Type: multipart/alternative; boundary="=_alternative 0015474A85256F62_=" Received-SPF: none (bart.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/OFD5F5D3C3.FC85E915-ON85256F62.001409A8-85256F62.0015474B@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9128 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 03:52:55 +0000 This is a multipart message in MIME format. --=_alternative 0015474A85256F62_= Content-Type: text/plain; charset="US-ASCII" Julian wrote on 12/03/2004 03:44:41 PM: > Jim Whitehead wrote: > > > Lock really should > > ignore any loopback binding. While loopback bindings could theoretically > > have existed in the 2518 world, it really is only the introduction of the > > BIND specification that starts raising these issues with any urgency. > > Well, there are good reasons not to implement bind loops at all (this is > why the spec explicitly allows servers to reject requests creating them, > see DAV:cycle-allowed precondition for BIND). The presence of bind loops > creates all kinds of issues, including those what to do with > PROPFIND/depth:infinity and code that walks hierarchies and gets into > infinite loops. I'm not surprised that Depth:infinity locks in bind > loops are hard to handle, but IMHO that only means that one should avoid > bind loops :-) Bind loops are fine. Depth:infinity applied to bind loops is what causes the problem. As Julian indicates, how a particular server decides to handle Depth:infinity locks in the presence of bind loops (for those very rare servers, if any, that actually support this) will be very idiosyncratic to that particular server. It may decide to fail a Depth:infinity lock applied to a loop, or it may decide to lock all the resources included in the loop. Or it may decide to do something totally bizarre(:-) such as Jim's suggestion, that it lock only resources that aren't parents of the resource being locked. We need to maintain a discrete silence here, since we really can't predict what a server will need to do, or be able to do, in a case like this. But this is a very unlikely edge case, and therefore I believe doesn't merit any spec space devoted to it. > I remember that Geoff was actually defending the ability to have bind > loops, so maybe he can offer some opinion about how locks should behave. We will not be supporting depth locks in our loop-supporting repostories. > Personally, I'd say: "the way they are defined by RFC2518, and if this > hurts, don't do it". I agree, where by "don't do it", I assume you mean "fail an attempt to create the lock", and it's got a well-defined error code (506) it it decides to do so. Cheers, Geoff --=_alternative 0015474A85256F62_= Content-Type: text/html; charset="US-ASCII"
Julian wrote on 12/03/2004 03:44:41 PM:

> Jim Whitehead wrote:
>
> > Lock really should
> > ignore any loopback binding. While loopback bindings could theoretically
> > have existed in the 2518 world, it really is only the introduction of the
> > BIND specification that starts raising these issues with any urgency.
>
> Well, there are good reasons not to implement bind loops at all (this is
> why the spec explicitly allows servers to reject requests creating them,
> see DAV:cycle-allowed precondition for BIND). The presence of bind loops
> creates all kinds of issues, including those what to do with
> PROPFIND/depth:infinity and code that walks hierarchies and gets into
> infinite loops. I'm not surprised that Depth:infinity locks in bind
> loops are hard to handle, but IMHO that only means that one should avoid
> bind loops :-)
Bind loops are fine.  Depth:infinity applied to bind loops is what
causes the problem.  As Julian indicates, how a particular server decides
to handle Depth:infinity locks in the presence of bind loops (for those
very rare servers, if any, that actually support this) will be very
idiosyncratic to that particular server.  It may decide to fail
a Depth:infinity lock applied to a loop, or it may decide to lock all
the resources included in the loop.  Or it may decide to do something
totally bizarre(:-) such as Jim's suggestion, that it lock only resources
that aren't parents of the resource being locked.  We need to maintain
a discrete silence here, since we really can't predict what a server
will need to do, or be able to do, in a case like this.  But this is
a very unlikely edge case, and therefore I believe doesn't merit any
spec space devoted to it.

> I remember that Geoff was actually defending the ability to have bind
> loops, so maybe he can offer some opinion about how locks should behave.

We will not be supporting depth locks in our loop-supporting repostories.

> Personally, I'd say: "the way they are defined by RFC2518, and if this
> hurts, don't do it".

I agree, where by "don't do it", I assume you mean "fail an attempt to
create the lock", and it's got a well-defined error code (506) it it
decides to do so.

Cheers,
Geoff




--=_alternative 0015474A85256F62_=-- From w3c-dist-auth-request@w3.org Sun Dec 5 23:06:18 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08823 for ; Sun, 5 Dec 2004 23:06:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbA7z-0004gg-Kp for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 04:05:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbA7z-0004gC-8u for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 04:05:35 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by lisa.w3.org with esmtp (Exim 4.34) id 1CbA7s-0005KZ-4K for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 04:05:28 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB6454Mm022972 for ; Sun, 5 Dec 2004 23:05:04 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB6454jD254712 for ; Sun, 5 Dec 2004 23:05:04 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB6454mH004834 for ; Sun, 5 Dec 2004 23:05:04 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB6454fl004831 for ; Sun, 5 Dec 2004 23:05:04 -0500 In-Reply-To: <41B0E830.6060804@gmx.de> To: "'WebDAV (WebDAV WG)'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Sun, 5 Dec 2004 23:05:07 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/05/2004 23:05:04, Serialize complete at 12/05/2004 23:05:04 Content-Type: multipart/alternative; boundary="=_alternative 0016708F85256F62_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/OF989FF40D.BE691AF9-ON85256F62.00154D4F-85256F62.00167090@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9129 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 04:05:35 +0000 This is a multipart message in MIME format. --=_alternative 0016708F85256F62_= Content-Type: text/plain; charset="US-ASCII" Julian wrote on 12/03/2004 05:26:56 PM: > Jim Whitehead wrote: > > > The reason I think this is an issue is that I can't envision a scenario > > where you would ever want the lock to follow a loopback binding. That is, > > the reason it is a problem is the locks-follow-the-loopback-binding > > semantics are never what a client would want. > > I'll not argue with that. But to me this means that if you don't want > that, don't do it. The fact that depth:infinity locks have interestings > results for bind loops doesn't necessarily mean that the base semantics > need to be changed; not doing it if you don't want to certainly is an > option as well (and a much simpler one spec-wise). I completely agree. Throw a 506 if you don't want to follow the base semantics. > > You can make consistent semantics here, by saying that locks always > > propagate down a hierarchy, but never up. Yes, this is changing the base > > lock semantics somewhat, but in my opinion it doesn't violate the intent of > > 2518. This is essentially adapting the COPY depth infinity semantics for > > locks. > > Sounds interesting; but as I'd like to hear feedback from those who > actually see bind loops being used in practice. Geoff?? I don't believe any server would actually maintain a depth:Infinity lock only on the "non-ancestor" members, since it would have to perform expensive recomputations on all involved locks every time a binding was changed. It will either do the base semantics (and bind everything) or fail the depth:lock or the attempt to loop-back under a depth-lock (with a 506). We just won't support depth locks on our loop-backing repositories. > >>Well, there are good reasons not to implement bind loops at > >>all (this is why the spec explicitly allows servers to reject > >>requests creating them, see DAV:cycle-allowed precondition > >>for BIND). The presence of bind loops creates all kinds of > >>issues, including those what to do with > >>PROPFIND/depth:infinity and code that walks hierarchies and > >>gets into infinite loops. I'm not surprised that > >>Depth:infinity locks in bind loops are hard to handle, but > >>IMHO that only means that one should avoid bind loops :-) > > > > Saying "tut-tut" doesn't make the problems of the interactions of loopback > > bindings and depth locks go away. Pragmatically, a server will do some combination of: - support the base semantics, - fail attempts to create loops, - fail attempts to do depth locks, - fail attempts to create a loop under a depth lock, or - fail attempts to depth lock over a loop None of these require additional statements in the specification, and we really cannot (and should not) try to dictate which of these it does. And we certainly should dictate it do something computationally infeasible instead (:-). > >>Personally, I'd say: "the way they are defined by RFC2518, > >>and if this hurts, don't do it". > > > > We can be more nuanced than this. > > We *could*. The question is: do we want to complicate the spec for > something that seems to be an edge case? As far as I am concerned, bind > loops are something that most implementers won't implement anyway. Let's > hear from those who actually want bind loops about what they think about > how they should behave with locking. I agree we should not try to be more nuanced. The current definitions give the servers all the alternatives they are likely to pick. Cheers, Geoff --=_alternative 0016708F85256F62_= Content-Type: text/html; charset="US-ASCII"
Julian wrote on 12/03/2004 05:26:56 PM:

> Jim Whitehead wrote:
>
> > The reason I think this is an issue is that I can't envision a scenario
> > where you would ever want the lock to follow a loopback binding. That is,
> > the reason it is a problem is the locks-follow-the-loopback-binding
> > semantics are never what a client would want.
>
> I'll not argue with that. But to me this means that if you don't want
> that, don't do it. The fact that depth:infinity locks have interestings
> results for bind loops doesn't necessarily mean that the base semantics
> need to be changed; not doing it if you don't want to certainly is an
> option as well (and a much simpler one spec-wise).

I completely agree.  Throw a 506 if you don't want to follow the base
semantics.

> > You can make consistent semantics here, by saying that locks always
> > propagate down a hierarchy, but never up. Yes, this is changing the base
> > lock semantics somewhat, but in my opinion it doesn't violate the intent of
> > 2518. This is essentially adapting the COPY depth infinity semantics for
> > locks.
>
> Sounds interesting; but as I'd like to hear feedback from those who
> actually see bind loops being used in practice. Geoff??

I don't believe any server would actually maintain a depth:Infinity
lock only on the "non-ancestor" members, since it would have to perform
expensive recomputations on all involved locks every time a binding
was changed.  It will either do the base semantics (and bind everything)
or fail the depth:lock or the attempt to loop-back under a depth-lock
(with a 506).  We just won't support depth locks on our loop-backing
repositories.

> >>Well, there are good reasons not to implement bind loops at
> >>all (this is why the spec explicitly allows servers to reject
> >>requests creating them, see DAV:cycle-allowed precondition
> >>for BIND). The presence of bind loops creates all kinds of
> >>issues, including those what to do with
> >>PROPFIND/depth:infinity and code that walks hierarchies and
> >>gets into infinite loops. I'm not surprised that
> >>Depth:infinity locks in bind loops are hard to handle, but
> >>IMHO that only means that one should avoid bind loops :-)
> >
> > Saying "tut-tut" doesn't make the problems of the interactions of loopback
> > bindings and depth locks go away.

Pragmatically, a server will do some combination of:
- support the base semantics,
- fail attempts to create loops,
- fail attempts to do depth locks,
- fail attempts to create a loop under a depth lock, or
- fail attempts to depth lock over a loop

None of these require additional statements in the specification,
and we really cannot (and should not) try to dictate which of these
it does.  And we certainly should dictate it do something computationally
infeasible instead (:-).

> >>Personally, I'd say: "the way they are defined by RFC2518,
> >>and if this hurts, don't do it".
> >
> > We can be more nuanced than this.
>
> We *could*. The question is: do we want to complicate the spec for
> something that seems to be an edge case? As far as I am concerned, bind
> loops are something that most implementers won't implement anyway. Let's
> hear from those who actually want bind loops about what they think about
> how they should behave with locking.

I agree we should not try to be more nuanced.
The current definitions give the servers all the alternatives they are likely
to pick.

Cheers,
Geoff


--=_alternative 0016708F85256F62_=-- From w3c-dist-auth-request@w3.org Mon Dec 6 03:07:46 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09781 for ; Mon, 6 Dec 2004 03:07:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbDst-00054F-TH for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 08:06:15 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbDss-00053T-F8 for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 08:06:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CbDsl-000494-8m for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 08:06:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB686C27017596; Mon, 6 Dec 2004 00:06:12 -0800 Date: Mon, 6 Dec 2004 00:06:12 -0800 Message-Id: <200412060806.iB686C27017596@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 70] REBIND arguments should be like BIND X-Archived-At: http://www.w3.org/mid/200412060806.iB686C27017596@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9130 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 08:06:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=70 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-06 00:06 ------- This is correct and has been fixed in the latest edits. See also . ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Mon Dec 6 05:27:34 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20913 for ; Mon, 6 Dec 2004 05:27:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbG4W-0005uS-H8 for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 10:26:24 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CbG4U-0005tn-Uo for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 10:26:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CbG4U-00005s-ME for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 10:26:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB6AQLXP026107; Mon, 6 Dec 2004 02:26:21 -0800 Date: Mon, 6 Dec 2004 02:26:21 -0800 Message-Id: <200412061026.iB6AQLXP026107@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 70] REBIND arguments should be like BIND X-Archived-At: http://www.w3.org/mid/200412061026.iB6AQLXP026107@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9131 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 10:26:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=70 ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-06 02:26 ------- Updated text from -latest version: 6. REBIND Method The REBIND method removes a binding to a resource from a collection, and adds a binding to that resource into the collection identified by the Request-URI. The request body specifies the binding to be added (segment) and the old binding to be removed (href). It is effectively an atomic form of a MOVE request, and MUST be treated the same way as MOVE for the purpose of determining access permissions. If a REBIND request fails, the server state preceding the request MUST be restored. This method is unsafe and idempotent (see [RFC2616], section 9.1). Marshalling: The request MAY include an Overwrite header. The request body MUST be a DAV:rebind XML element. If the request succeeds, the server MUST return 201 (Created) when a new binding was created and 200 (OK) when an existing binding was replaced. If a response body for a successful request is included, it MUST be a DAV:rebind-response XML element. Note that this document does not define any elements for the REBIND response body, but the DAV:rebind-response element is defined to ensure interoperability between future extensions that do define elements for the REBIND response body. Preconditions: (DAV:rebind-into-collection): The Request-URI MUST identify a collection. (DAV:rebind-source-exists): The DAV:href element MUST identify a resource. (DAV:cross-server-binding): If the resource identified by the DAV:href element in the request body is on another server from the collection identified by the Request-URI, the server MUST support cross-server bindings. (DAV:name-allowed): The name specified by the DAV:segment is available for use as a new binding name. (DAV:can-overwrite): If the collection already contains a binding with the specified path segment, and if an Overwrite header is included, the value of the Overwrite header MUST be "T". (DAV:cycle-allowed): If the DAV:href element identifies a collection, and if the Request-URI identifies a collection that is a member of that collection, the server MUST support cycles in the URI namespace. (DAV:locked-update-allowed): If the collection identified by the Request-URI is write-locked, then the appropriate token MUST be specified in the request. (DAV:protected-url-modification-allowed): If the collection identified by the Request-URI already contains a binding with the specified path segment, and if that binding is protected by a write-lock, then the appropriate token MUST be specified in the request. (DAV:locked-source-collection-update-allowed): If the collection identified by the parent collection prefix of the DAV:href URI is write-locked, then the appropriate token MUST be specified in the request. (DAV:protected-source-url-deletion-allowed): If the DAV:href URI is protected by a write lock, then the appropriate token MUST be specified in the request. Postconditions: (DAV:new-binding): The collection MUST have a binding that maps the segment specified in the DAV:segment element in the request body, to the resource that was identified by the DAV:href element in the request body. (DAV:binding-deleted): The URL specified in the DAV:href element in the request body MUST NOT be mapped to a resource. (DAV:lock-deleted): If the URL specified in the DAV:href element in the request body was protected by a write-lock at the time of the request, that write-lock must have been deleted by the request. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Mon Dec 6 05:49:21 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22173 for ; Mon, 6 Dec 2004 05:49:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbGQ0-0007lN-M4 for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 10:48:36 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CbGQ0-0007kb-CX for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 10:48:36 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CbGQ0-00087z-2W for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 10:48:36 +0000 Received: (qmail 5888 invoked by uid 65534); 6 Dec 2004 10:48:03 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.18]) (217.5.201.10) by mail.gmx.net (mp019) with SMTP; 06 Dec 2004 11:48:03 +0100 X-Authenticated: #1915285 Message-ID: <41B438E2.6090408@gmx.de> Date: Mon, 06 Dec 2004 11:48:02 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: "'WebDAV (WebDAV WG)'" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/41B438E2.6090408@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9132 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 10:48:36 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > Julian wrote on 12/03/2004 03:44:41 PM: > > > Jim Whitehead wrote: > > > > > Lock really should > > > ignore any loopback binding. While loopback bindings could > theoretically > > > have existed in the 2518 world, it really is only the introduction > of the > > > BIND specification that starts raising these issues with any urgency. > > > > Well, there are good reasons not to implement bind loops at all (this is > > why the spec explicitly allows servers to reject requests creating them, > > see DAV:cycle-allowed precondition for BIND). The presence of bind loops > > creates all kinds of issues, including those what to do with > > PROPFIND/depth:infinity and code that walks hierarchies and gets into > > infinite loops. I'm not surprised that Depth:infinity locks in bind > > loops are hard to handle, but IMHO that only means that one should avoid > > bind loops :-) > > Bind loops are fine. Depth:infinity applied to bind loops is what > causes the problem. As Julian indicates, how a particular server decides > to handle Depth:infinity locks in the presence of bind loops (for those > very rare servers, if any, that actually support this) will be very > idiosyncratic to that particular server. It may decide to fail > a Depth:infinity lock applied to a loop, or it may decide to lock all > the resources included in the loop. Or it may decide to do something > totally bizarre(:-) such as Jim's suggestion, that it lock only resources > that aren't parents of the resource being locked. We need to maintain > a discrete silence here, since we really can't predict what a server > will need to do, or be able to do, in a case like this. But this is > a very unlikely edge case, and therefore I believe doesn't merit any > spec space devoted to it. > > > I remember that Geoff was actually defending the ability to have bind > > loops, so maybe he can offer some opinion about how locks should behave. > > We will not be supporting depth locks in our loop-supporting repostories. > > > Personally, I'd say: "the way they are defined by RFC2518, and if this > > hurts, don't do it". > > I agree, where by "don't do it", I assume you mean "fail an attempt to > create the lock", and it's got a well-defined error code (506) it it > decides to do so. OK, to summarize: as far as Geoff and I (as most recent editors of the spec is concerned), the intent indeed is that RFC2518 semantics apply, and this is the reason why the spec is silent on it. Jim, does this settle the question, or should I add this to the document's issues list? Regarding the process, I'd like to submit a new draft this week, and I think that one should be WG-last-called. If we do a 4-week last call, people of plenty of time to review it until mid of January. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 6 07:27:33 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02428 for ; Mon, 6 Dec 2004 07:27:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbHwR-0000Xm-Pw for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 12:26:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbHwQ-0000VQ-3u for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 12:26:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CbHwI-0003wW-Of for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 12:26:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iB6CQ8Aq002641; Mon, 6 Dec 2004 04:26:08 -0800 Date: Mon, 6 Dec 2004 04:26:08 -0800 Message-Id: <200412061226.iB6CQ8Aq002641@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 70] REBIND arguments should be like BIND X-Archived-At: http://www.w3.org/mid/200412061226.iB6CQ8Aq002641@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9133 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 12:26:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=70 geoffrey.clemm@us.ibm.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Mon Dec 6 12:24:39 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01807 for ; Mon, 6 Dec 2004 12:24:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbMYt-0000VQ-I6 for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 17:22:11 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CbMYs-0000Ur-06 for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 17:22:10 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by bart.w3.org with esmtp (Exim 4.34) id 1CbMYr-0005A3-OO for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 17:22:09 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB6HLFQ7021628 for ; Mon, 6 Dec 2004 09:21:18 -0800 (PST) Message-Id: <200412061721.iB6HLFQ7021628@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Mon, 6 Dec 2004 09:21:06 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTbRyMGH1WKL68RR4appf7OjWJHpQAbY9Hg X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/200412061721.iB6HLFQ7021628@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9134 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 17:22:11 +0000 Content-Transfer-Encoding: 7bit Geoff Clemm writes: > Bind loops are fine. Depth:infinity applied to bind loops is what > causes the problem. As Julian indicates, how a particular server decides > to handle Depth:infinity locks in the presence of bind loops (for those > very rare servers, if any, that actually support this) will be very > idiosyncratic to that particular server. My assertion is the semantics of Depth infinity locks and loopback bindings will be very consistent -- servers will ignore loopback edges when computing the closure of the containment graph of a collection for the purpose of locking. This is a very consistent semantics, one that is easy to specify, and easy to understand. Furthermore, I also assert that there is no reasonable scenario under which a server would ever want to follow the loopback bindings when computing Depth infinity closure. Given this, we would be acting responsibly as specification writers to clarify the semantics of this situation, and to close off undesirable semantics. > We need to maintain > a discrete silence here, since we really can't predict what a server > will need to do, or be able to do, in a case like this. But this is > a very unlikely edge case, and therefore I believe doesn't merit any > spec space devoted to it. I don't think we can reasonably predict how many servers will implement both loopback bindings and depth locks. We do know there is a feature interaction issue here. We also have sufficient experience to be able to analytically determine that allowing locks to follow loopback bindings can cause an operation to have unexpected scope of impact from a user-directing-a-client perspective. We need some SHOULD-level guidance for servers that decide to support both depth locks and loopback bindings. (I personally think it could be MUST-level, but would be happy with at least SHOULD). It is negligent to duck this feature interaction. All servers that currently implement depth locks and plan on implementing the BIND specification will need to make decisions about how to handle this interaction, whether by disallowing loopback bindings, depth locks of loopbacked collectioned, etc. At the very least we need an implementation note outlining Geoff's options so implementors can make reasoned decisions about how to duck the issue. Even better would be supplementing this with feedback on how to do a good job of providing both features simultaneously. - Jim From w3c-dist-auth-request@w3.org Mon Dec 6 12:42:25 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03667 for ; Mon, 6 Dec 2004 12:42:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbMrp-00079S-Ld for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 17:41:45 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CbMrp-00076y-C8 for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 17:41:45 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1CbMro-0003Uz-Ky for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 17:41:45 +0000 Received: from [192.168.1.26] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.1.R) with ESMTP id md50000066247.msg for ; Mon, 06 Dec 2004 18:40:40 +0100 In-Reply-To: <200412061721.iB6HLFQ7021628@cats-mx3.ucsc.edu> References: <200412061721.iB6HLFQ7021628@cats-mx3.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'WebDAV \(WebDAV WG\)'" From: Stefan Eissing Date: Mon, 6 Dec 2004 18:40:34 +0100 To: X-Mailer: Apple Mail (2.619) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Mon, 06 Dec 2004 18:40:40 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Received-SPF: none (bart.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/EEFD5EBA-47AD-11D9-8A53-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9135 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 17:41:45 +0000 Content-Transfer-Encoding: 7bit May I ask what the definition of a "loopback binding" is and how it differs from other bindings? In my concept, all bindings are created equal and which binding "loops back" to where depends on the path you take when traversing collection "trees", as I see it. From mathematical perspective, bindings transform the well known *tree* into a directed graph. Some servers will require acyclic graphs while others will allow cycles. The set of deep-locked nodes is the set of nodes reachable from the starting point. We could provide an algorithm for server implementors, and even more important for clients, on how to find this set and not get lost in possible cycles. Stefan Am 06.12.2004 um 18:21 schrieb Jim Whitehead: > > Geoff Clemm writes: > >> Bind loops are fine. Depth:infinity applied to bind loops is what >> causes the problem. As Julian indicates, how a particular server >> decides >> to handle Depth:infinity locks in the presence of bind loops (for >> those >> very rare servers, if any, that actually support this) will be very >> idiosyncratic to that particular server. > > My assertion is the semantics of Depth infinity locks and loopback > bindings > will be very consistent -- servers will ignore loopback edges when > computing > the closure of the containment graph of a collection for the purpose of > locking. This is a very consistent semantics, one that is easy to > specify, > and easy to understand. > > Furthermore, I also assert that there is no reasonable scenario under > which > a server would ever want to follow the loopback bindings when computing > Depth infinity closure. Given this, we would be acting responsibly as > specification writers to clarify the semantics of this situation, and > to > close off undesirable semantics. > >> We need to maintain >> a discrete silence here, since we really can't predict what a server >> will need to do, or be able to do, in a case like this. But this is >> a very unlikely edge case, and therefore I believe doesn't merit any >> spec space devoted to it. > > I don't think we can reasonably predict how many servers will > implement both > loopback bindings and depth locks. > > We do know there is a feature interaction issue here. We also have > sufficient experience to be able to analytically determine that > allowing > locks to follow loopback bindings can cause an operation to have > unexpected > scope of impact from a user-directing-a-client perspective. We need > some > SHOULD-level guidance for servers that decide to support both depth > locks > and loopback bindings. (I personally think it could be MUST-level, but > would > be happy with at least SHOULD). > > It is negligent to duck this feature interaction. All servers that > currently > implement depth locks and plan on implementing the BIND specification > will > need to make decisions about how to handle this interaction, whether by > disallowing loopback bindings, depth locks of loopbacked collectioned, > etc. > At the very least we need an implementation note outlining Geoff's > options > so implementors can make reasoned decisions about how to duck the > issue. > Even better would be supplementing this with feedback on how to do a > good > job of providing both features simultaneously. > > - Jim > > > > > > > > From w3c-dist-auth-request@w3.org Mon Dec 6 12:53:24 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04426 for ; Mon, 6 Dec 2004 12:53:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbN2R-00048u-Ot for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 17:52:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbN2R-00048G-Hh for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 17:52:43 +0000 Received: from cats-mx1.ucsc.edu ([128.114.125.34]) by lisa.w3.org with esmtp (Exim 4.34) id 1CbN2K-0000Xq-Ah for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 17:52:36 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx1.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB6HpF9j020768; Mon, 6 Dec 2004 09:51:18 -0800 (PST) Message-Id: <200412061751.iB6HpF9j020768@cats-mx1.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Stefan Eissing'" Cc: "'WebDAV \(WebDAV WG\)'" Date: Mon, 6 Dec 2004 09:51:06 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTbutshurvIoWz7Sg2YXxnyJi8xeAAAChgg X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/200412061751.iB6HpF9j020768@cats-mx1.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9136 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 17:52:43 +0000 Content-Transfer-Encoding: 7bit > May I ask what the definition of a "loopback binding" is and > how it differs from other bindings? A rough definition is any binding that converts an acyclic containment graph into a cyclic graph. This is also how it differs from other bindings. > Some servers will require > acyclic graphs while others will allow cycles. Right. In the case where servers support cycles, and also support depth locks, they'll need to develop semantics for the interaction of these two features. At present, the bind specification provides no guidance for this situation. > The set of deep-locked nodes is the set of nodes reachable > from the starting point. We could provide an algorithm for > server implementors, and even more important for clients, on > how to find this set and not get lost in possible cycles. We could do this, although I'd rather not get into specifying which kind of traversal algorithm servers should use (depth first vs breadth first, etc.), since that's implementation detail. I'd rather point out that, no matter which kind of traversal you use to compute closure, there are certain edges (loopback edges) that should not be followed in computing the closure. - Jim From w3c-dist-auth-request@w3.org Mon Dec 6 13:16:49 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07322 for ; Mon, 6 Dec 2004 13:16:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbNOy-00049m-CZ for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 18:16:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbNOx-000488-UB for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 18:15:59 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CbNOq-0000C9-N6 for w3c-dist-auth@w3c.org; Mon, 06 Dec 2004 18:15:52 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB6IFqaa032440 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 6 Dec 2004 10:15:58 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> References: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Mon, 6 Dec 2004 10:15:41 -0800 To: Webdav WG X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/D6927A80-47B2-11D9-A94C-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9137 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 18:16:00 +0000 Content-Transfer-Encoding: 7bit This bug/issue has been repeatedly closed "worksforme". I do not agree that the issue is closed. What is our model for whether a bug can be closed or not? Lisa On Dec 5, 2004, at 6:39 PM, bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3 > > > > > > ------- Additional Comments From geoffrey.clemm@us.ibm.com 2004-12-05 > 18:39 ------- > Since RFC 2518 allows two URIs to map to the same resource, it is the > responsibility of RFC-2518 to define the semantics of properties when > accessed > from different URIs that map to the same resource. The bindings draft > will > inherit whatever semantics is defined for this by 2518. > > If there is ambiguity in semantics introduced by 2518, it should be > fixed in > 2518bis, not in the bindings draft. Having one spec define the > functionality > of a feature defined by another spec is always a bad idea, since > unless the > two specs are evolved in lock step (which never happens), there will be > periods of times when the two specs say conflicting things about that > feature. > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. From w3c-dist-auth-request@w3.org Mon Dec 6 13:28:15 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08055 for ; Mon, 6 Dec 2004 13:28:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbNZl-0000pi-L5 for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 18:27:09 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CbNZl-0000p4-Cj for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 18:27:09 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CbNZk-0005Kl-Nd for w3c-dist-auth@w3c.org; Mon, 06 Dec 2004 18:27:09 +0000 Received: (qmail 9189 invoked by uid 65534); 6 Dec 2004 18:26:33 -0000 Received: from pD95351AC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.81.172) by mail.gmx.net (mp004) with SMTP; 06 Dec 2004 19:26:32 +0100 X-Authenticated: #1915285 Message-ID: <41B4A44C.8070803@gmx.de> Date: Mon, 06 Dec 2004 19:26:20 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Webdav WG References: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41B4A44C.8070803@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9138 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 18:27:09 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > This bug/issue has been repeatedly closed "worksforme". I do not agree > that the issue is closed. What is our model for whether a bug can be > closed or not? Well, it has also been re-opened, with which *I* don't agree. What does this tell us? BugZilla is just a tool for keeping track of issues, but it does not help defining rough consensus. As stated before, a situation where a single voice continues to re-raise the same issue, but everybody else appears to agree that there is no problem, seems to be exactly the case where the term "rough consensus" applies. See also . Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 6 13:57:00 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11953 for ; Mon, 6 Dec 2004 13:57:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbO1v-0003TC-4g for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 18:56:15 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CbO1u-0003Sh-T0 for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 18:56:14 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CbO1u-0000Se-Lp for w3c-dist-auth@w3c.org; Mon, 06 Dec 2004 18:56:14 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3c.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB6Itoaa002127 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Dec 2004 10:55:56 -0800 In-Reply-To: <41B4A44C.8070803@gmx.de> References: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> <41B4A44C.8070803@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Webdav WG From: Lisa Dusseault Date: Mon, 6 Dec 2004 10:55:42 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9139 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 18:56:15 +0000 Content-Transfer-Encoding: 7bit I don't think everybody else agrees that there is no problem. I have only heard a couple people directly address this issue. The last time we discussed this (this fall but also way earlier), we did come to rough consensus that properties, even live properties, must have the same value no matter which binding is used to request the value of the property. (I am not sure I agree with the conclusion, but I agree there was rough consensus.) Now I'm saying that it's not clear in the spec that this is required and we should put it in the spec. This is a different issue (what should be in the spec) than the previous issue ( what should be allowed) although clearly one follows from the other. In the message you point to, Geoff and Jason and yourself addressed the "what should be allowed" issue. Now let's discuss "what should be in the spec". Lisa On Dec 6, 2004, at 10:26 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> This bug/issue has been repeatedly closed "worksforme". I do not >> agree that the issue is closed. What is our model for whether a bug >> can be closed or not? > > Well, it has also been re-opened, with which *I* don't agree. What > does this tell us? BugZilla is just a tool for keeping track of > issues, but it does not help defining rough consensus. > > As stated before, a situation where a single voice continues to > re-raise the same issue, but everybody else appears to agree that > there is no problem, seems to be exactly the case where the term > "rough consensus" applies. > > See also > 0025.html>. > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 6 14:18:33 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14030 for ; Mon, 6 Dec 2004 14:18:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbOMn-0003Md-A4 for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 19:17:49 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CbOMn-0003L3-1P for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 19:17:49 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by bart.w3.org with esmtp (Exim 4.34) id 1CbOMm-0000GK-P7 for w3c-dist-auth@w3c.org; Mon, 06 Dec 2004 19:17:48 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB6JErCF012946 for ; Mon, 6 Dec 2004 11:15:00 -0800 (PST) Message-Id: <200412061915.iB6JErCF012946@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Webdav WG'" Date: Mon, 6 Dec 2004 11:14:47 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTbxUxlsvrA/7/TQamglF32YG5GBwAARsDA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/200412061915.iB6JErCF012946@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9140 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 19:17:49 +0000 Content-Transfer-Encoding: 7bit I think it would be good to include the following language in the bind specification: Note that, consistent with [RFC2518], the value of a dead property is independent of the number of bindings to its host resource, and of the path submitted to PROPFIND. Since live properties can be aribtrary computational processes, they MAY vary depending on path or number of bindings, but SHOULD NOT do this unless the definition of the live property explicitly includes this dependency. Here I avoided adding new requirements in areas already covered by 2518, but did add requirements for the new situation raised by the BIND specification. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Lisa Dusseault > Sent: Monday, December 06, 2004 10:56 AM > To: Julian Reschke > Cc: Webdav WG > Subject: Re: [Bug 3] Bindings draft should specify if all > properties MUST have same value on all bindings > > > I don't think everybody else agrees that there is no problem. > I have only heard a couple people directly address this issue. > > The last time we discussed this (this fall but also way > earlier), we did come to rough consensus that properties, > even live properties, must have the same value no matter > which binding is used to request the value of the property. > (I am not sure I agree with the conclusion, but I agree there > was rough consensus.) > > Now I'm saying that it's not clear in the spec that this is > required and we should put it in the spec. This is a > different issue (what should be in the spec) than the > previous issue ( what should be > allowed) although clearly one follows from the other. In > the message > you point to, Geoff and Jason and yourself addressed the > "what should be allowed" issue. Now let's discuss "what > should be in the spec". > > Lisa > > On Dec 6, 2004, at 10:26 AM, Julian Reschke wrote: > > > Lisa Dusseault wrote: > >> This bug/issue has been repeatedly closed "worksforme". I do not > >> agree that the issue is closed. What is our model for > whether a bug > >> can be closed or not? > > > > Well, it has also been re-opened, with which *I* don't agree. What > > does this tell us? BugZilla is just a tool for keeping track of > > issues, but it does not help defining rough consensus. > > > > As stated before, a situation where a single voice continues to > > re-raise the same issue, but everybody else appears to agree that > > there is no problem, seems to be exactly the case where the term > > "rough consensus" applies. > > > > See also > > > 0025.html>. > > > > Best regards, Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Mon Dec 6 15:05:03 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19550 for ; Mon, 6 Dec 2004 15:05:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbP5S-0003fC-Gd for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 20:03:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbP5Q-0003di-QC for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 20:03:56 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CbP5J-0000iO-5r for w3c-dist-auth@w3c.org; Mon, 06 Dec 2004 20:03:49 +0000 Received: (qmail 4993 invoked by uid 65534); 6 Dec 2004 20:03:22 -0000 Received: from pD95351AC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.81.172) by mail.gmx.net (mp007) with SMTP; 06 Dec 2004 21:03:22 +0100 X-Authenticated: #1915285 Message-ID: <41B4BB03.7050505@gmx.de> Date: Mon, 06 Dec 2004 21:03:15 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Webdav WG References: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> <41B4A44C.8070803@gmx.de> <6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org> In-Reply-To: <6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41B4BB03.7050505@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9141 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 20:03:58 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I don't think everybody else agrees that there is no problem. I have > only heard a couple people directly address this issue. Well, I can only make statements about people who *do* say something about the topic. Those who did seemed to agree that the spec shouldn't say anything specific about this issue. > The last time we discussed this (this fall but also way earlier), we > did come to rough consensus that properties, even live properties, must > have the same value no matter which binding is used to request the > value of the property. (I am not sure I agree with the conclusion, but > I agree there was rough consensus.) > > Now I'm saying that it's not clear in the spec that this is required > and we should put it in the spec. This is a different issue (what > should be in the spec) than the previous issue ( what should be > allowed) although clearly one follows from the other. In the message > you point to, Geoff and Jason and yourself addressed the "what should > be allowed" issue. Now let's discuss "what should be in the spec". I'm happy to discuss the issue "what should be in the spec". However, BIND does *not* introduce the concept of bindings. What it introduces is a new method for explicitly creating them (BIND), some BIND-optimized equivalents for MOVE and DELETE (REBIND and UNBIND), live properties and status codes that help in living with multiple bindings. But the basic concept of multiple URIs being mapped to the same URI is already present in RFC2518, thus if there is anything that needs to be clarified regarding the behaviour of properties, this needs to go into RFC2518 (as Jim already mentioned, the containment model described in the BIND spec really should be part of the base spec, not BIND). So should I open an issue against RFC2518bis regarding this topic? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 6 15:11:14 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20286 for ; Mon, 6 Dec 2004 15:11:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbPBZ-0006K7-4e for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 20:10:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbPBY-0006JY-IE for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 20:10:16 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1CbPBR-00032z-7l for w3c-dist-auth@w3c.org; Mon, 06 Dec 2004 20:10:09 +0000 Received: (qmail 1907 invoked by uid 65534); 6 Dec 2004 20:09:44 -0000 Received: from pD95351AC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.81.172) by mail.gmx.net (mp009) with SMTP; 06 Dec 2004 21:09:44 +0100 X-Authenticated: #1915285 Message-ID: <41B4BC83.80709@gmx.de> Date: Mon, 06 Dec 2004 21:09:39 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'Webdav WG'" References: <200412061915.iB6JErCF012946@cats-mx3.ucsc.edu> In-Reply-To: <200412061915.iB6JErCF012946@cats-mx3.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41B4BC83.80709@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9142 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 20:10:17 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > I think it would be good to include the following language in the bind > specification: > > Note that, consistent with [RFC2518], the value of a dead property is > independent of the number of bindings to its host resource, and of the path > submitted to PROPFIND. Since live properties can be aribtrary computational > processes, they MAY vary depending on path or number of bindings, but SHOULD > NOT do this unless the definition of the live property explicitly includes > this dependency. > > > Here I avoided adding new requirements in areas already covered by 2518, but > did add requirements for the new situation raised by the BIND specification. I like that part that says that this is not a new requirement, but just a repeat of what RFC2518 already says. On the other hand, I'm less convinced that the second part is a good idea. Having property values varying across bindings is IMHO an extremely bad idea, and so far I haven't seen a good use case for them. Saying that specs MAY define these kinds of properties sort of encourages them. Anyway (and as mentioned in the reply to Lisa), this issue has nothing to do with BIND spec per se. Saying something in the BIND spec only makes sense if there is consensus to add equivalent language into RFC2518bis (and if this happens it's unclear why we need to add it to BIND in the first place). Feedback appreciated. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 6 15:20:26 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21582 for ; Mon, 6 Dec 2004 15:20:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbPKj-0000Tb-R9 for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 20:19:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbPKh-0000S4-3h for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 20:19:43 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CbPKZ-0006GM-QN for w3c-dist-auth@w3c.org; Mon, 06 Dec 2004 20:19:35 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3c.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB6KJcaa006248 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Dec 2004 12:19:39 -0800 In-Reply-To: <41B4BB03.7050505@gmx.de> References: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> <41B4A44C.8070803@gmx.de> <6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4BB03.7050505@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1EFA6E09-47C4-11D9-A94C-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Webdav WG From: Lisa Dusseault Date: Mon, 6 Dec 2004 12:19:24 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/1EFA6E09-47C4-11D9-A94C-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9143 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 20:19:45 +0000 Content-Transfer-Encoding: 7bit > > I'm happy to discuss the issue "what should be in the spec". However, > BIND does *not* introduce the concept of bindings. What it introduces > is a new method for explicitly creating them (BIND), some > BIND-optimized equivalents for MOVE and DELETE (REBIND and UNBIND), > live properties and status codes that help in living with multiple > bindings. But the basic concept of multiple URIs being mapped to the > same URI is already present in RFC2518, thus if there is anything that > needs to be clarified regarding the behaviour of properties, this > needs to go into RFC2518 (as Jim already mentioned, the containment > model described in the BIND spec really should be part of the base > spec, not BIND). > > So should I open an issue against RFC2518bis regarding this topic? > Only if RFC2518bis is going to include the whole bindings specification, or at least the resource-id property. The reason why RFC2518 never needed to answer this question definitively is because clients had no way of knowing when two URLs point to the same resource. If clients can't identify bindings, then there's no way to violate the client's expectations around property values of two bindings to the same resource. With the bindings specification, the client can detect multiple bindings with 'resource-id', or for that matter the client may have used BIND. So now that we have a spec describing how to identify and manipulate bindings, that spec needs to be clear on what the client must expect and/or what the server must do to meet expectations. Lisa From w3c-dist-auth-request@w3.org Mon Dec 6 15:56:44 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24343 for ; Mon, 6 Dec 2004 15:56:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbPtc-0005Q4-EQ for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 20:55:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbPta-0005PU-GT for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 20:55:46 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CbPtT-0000d8-6z for w3c-dist-auth@w3c.org; Mon, 06 Dec 2004 20:55:39 +0000 Received: (qmail 14550 invoked by uid 65534); 6 Dec 2004 20:55:14 -0000 Received: from pD95351AC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.81.172) by mail.gmx.net (mp017) with SMTP; 06 Dec 2004 21:55:14 +0100 X-Authenticated: #1915285 Message-ID: <41B4C72D.8060700@gmx.de> Date: Mon, 06 Dec 2004 21:55:09 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Webdav WG References: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> <41B4A44C.8070803@gmx.de> <6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4BB03.7050505@gmx.de> <1EFA6E09-47C4-11D9-A94C-000A95B2BB72@osafoundation.org> In-Reply-To: <1EFA6E09-47C4-11D9-A94C-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41B4C72D.8060700@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9144 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 20:55:48 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Only if RFC2518bis is going to include the whole bindings specification, > or at least the resource-id property. The reason why RFC2518 never > needed to answer this question definitively is because clients had no > way of knowing when two URLs point to the same resource. If clients > can't identify bindings, then there's no way to violate the client's > expectations around property values of two bindings to the same resource. If it doesn't matter, why does RFC2518 say: "Although implicit in [RFC2068] and [RFC2396], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs." () and "A resource may be made available through more than one URI. However locks apply to resources, not URIs. Therefore a LOCK request on a resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable." ()? > With the bindings specification, the client can detect multiple bindings > with 'resource-id', or for that matter the client may have used BIND. > So now that we have a spec describing how to identify and manipulate > bindings, that spec needs to be clear on what the client must expect > and/or what the server must do to meet expectations. I think it's safe to say that we'll continue to disagree on this. Multiple bindings to the same resource are part of RFC2518, even if it doesn't define the additional features in BIND (creation/discovery/diagnostics). So if there is anything unclear, it needs to be resolved in RFC2518bis as well. In which case the question arises why it would ever be a good idea to do it in two distinct places unless we can be absolutely certain that both say the same thing. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 6 17:03:03 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00255 for ; Mon, 6 Dec 2004 17:03:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbQvZ-0005ly-EM for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 22:01:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbQvX-0005lP-Lf for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 22:01:51 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CbQvQ-0003tj-Dc for w3c-dist-auth@w3c.org; Mon, 06 Dec 2004 22:01:44 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3c.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB6M1jaa012138 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Dec 2004 14:01:47 -0800 In-Reply-To: <41B4C72D.8060700@gmx.de> References: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> <41B4A44C.8070803@gmx.de> <6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4BB03.7050505@gmx.de> <1EFA6E09-47C4-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4C72D.8060700@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <666E83CC-47D2-11D9-A94C-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Webdav WG From: Lisa Dusseault Date: Mon, 6 Dec 2004 14:01:37 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/666E83CC-47D2-11D9-A94C-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9145 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 22:01:53 +0000 Content-Transfer-Encoding: 7bit On Dec 6, 2004, at 12:55 PM, Julian Reschke wrote: > Lisa Dusseault wrote: > >> Only if RFC2518bis is going to include the whole bindings >> specification, or at least the resource-id property. The reason why >> RFC2518 never needed to answer this question definitively is because >> clients had no way of knowing when two URLs point to the same >> resource. If clients can't identify bindings, then there's no way to >> violate the client's expectations around property values of two >> bindings to the same resource. > > If it doesn't matter, why does RFC2518 say: > > "Although implicit in [RFC2068] and [RFC2396], any resource, including > collection resources, MAY be identified by more than one URI. For > example, a resource could be identified by multiple HTTP URLs." > > () > and > > "A resource may be made available through more than one URI. However > locks apply to resources, not URIs. Therefore a LOCK request on a > resource MUST NOT succeed if can not be honored by all the URIs > through which the resource is addressable." > In this case it *does* matter to clients because it is detectable -- the behavior has concrete results, even if the client can't detect that there are multiple bindings. If a client is trying to allow the user to edit a resource and therefore locks the resource, then the resource gets changed anyway, this would violate the client's expectation. The client probably doesn't have a graceful way to recover from this kind of event even if the programmers are responsible in checking for it (by looking at the ETag). Therefore, this language is necessary to ensure that the lock covers the real resource and that the lock behaves the way the client expects it to. If we can come up with a use case where it's important for the client to rely on property values being the same for every binding to a resource, even without being able to tell that the resource has multiple bindings or what they are, then I will agree that RFC2518bis needs to cover that behavior as well. Lisa From w3c-dist-auth-request@w3.org Mon Dec 6 17:12:13 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00960 for ; Mon, 6 Dec 2004 17:12:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbR4u-0000OZ-OV for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 22:11:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbR4u-0000O1-BV for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 22:11:32 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CbR4n-0006aA-1y for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 22:11:25 +0000 Received: (qmail 23931 invoked by uid 65534); 6 Dec 2004 22:10:59 -0000 Received: from pD95351AC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.81.172) by mail.gmx.net (mp003) with SMTP; 06 Dec 2004 23:10:59 +0100 X-Authenticated: #1915285 Message-ID: <41B4D8ED.3020401@gmx.de> Date: Mon, 06 Dec 2004 23:10:53 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'Stefan Eissing'" , "'WebDAV (WebDAV WG)'" References: <200412061751.iB6HpF9j020768@cats-mx1.ucsc.edu> In-Reply-To: <200412061751.iB6HpF9j020768@cats-mx1.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/41B4D8ED.3020401@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9146 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 22:11:32 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: >>May I ask what the definition of a "loopback binding" is and >>how it differs from other bindings? > > > A rough definition is any binding that converts an acyclic containment graph > into a cyclic graph. This is also how it differs from other bindings. So, for a set of bindings that are part of that cyclic graph, which one is "causing" it? >>Some servers will require >>acyclic graphs while others will allow cycles. > > > Right. In the case where servers support cycles, and also support depth > locks, they'll need to develop semantics for the interaction of these two > features. At present, the bind specification provides no guidance for this > situation. IMHO it doesn't because it doesn't need to. As far as I can tell, until we say something else, the standard semantics apply (and as far as I can tell, it's clear what they define in this case). >>The set of deep-locked nodes is the set of nodes reachable >>from the starting point. We could provide an algorithm for >>server implementors, and even more important for clients, on >>how to find this set and not get lost in possible cycles. > > > We could do this, although I'd rather not get into specifying which kind of > traversal algorithm servers should use (depth first vs breadth first, etc.), > since that's implementation detail. As long as a server stops descending into a collection when it detects that it has visited that collection before, there doesn't seem to be an issue. > I'd rather point out that, no matter which kind of traversal you use to > compute closure, there are certain edges (loopback edges) that should not be > followed in computing the closure. IMHO deep locks on bind loops are an edge case, in particular if the bind loop includes the namespare root (as in the example we discussed). Is there anybody how already supports both or plans to support both and will *not* implement the standard RFC2518 deep lock semantics? BTW, another thing to keep in mind is that you don't need the BIND spec to create bind loops. Once you accept the existence of multiple URIs to the same resource, and the fact that these resources can be collections, a simple MOVE operation can create a BIND loop. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 6 17:21:30 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01558 for ; Mon, 6 Dec 2004 17:21:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbRDu-0004BZ-4T for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 22:20:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbRDt-0004B4-NO for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 22:20:49 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CbRDm-0001BY-Ds for w3c-dist-auth@w3c.org; Mon, 06 Dec 2004 22:20:42 +0000 Received: (qmail 24579 invoked by uid 65534); 6 Dec 2004 22:20:17 -0000 Received: from pD95351AC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.81.172) by mail.gmx.net (mp006) with SMTP; 06 Dec 2004 23:20:17 +0100 X-Authenticated: #1915285 Message-ID: <41B4DB1B.7020605@gmx.de> Date: Mon, 06 Dec 2004 23:20:11 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Webdav WG References: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> <41B4A44C.8070803@gmx.de> <6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4BB03.7050505@gmx.de> <1EFA6E09-47C4-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4C72D.8060700@gmx.de> <666E83CC-47D2-11D9-A94C-000A95B2BB72@osafoundation.org> In-Reply-To: <666E83CC-47D2-11D9-A94C-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41B4DB1B.7020605@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9147 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 22:20:50 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >> If it doesn't matter, why does RFC2518 say: >> >> "Although implicit in [RFC2068] and [RFC2396], any resource, including >> collection resources, MAY be identified by more than one URI. For >> example, a resource could be identified by multiple HTTP URLs." >> >> () and >> >> "A resource may be made available through more than one URI. However >> locks apply to resources, not URIs. Therefore a LOCK request on a >> resource MUST NOT succeed if can not be honored by all the URIs >> through which the resource is addressable." >> > > In this case it *does* matter to clients because it is detectable -- the > behavior has concrete results, even if the client can't detect that > there are multiple bindings. If a client is trying to allow the user to It's always detectable. For instance, if I submit a depth:0 LOCK request to "/a", and a subsequent PROPFIND on the DAV:lockdiscovery property of "/b" shows that it is locked by the same lock I just created on "/a", I can conclude that both are the same resource. BIND makes it *easier* to detect sameness, but it doesn't introduce any new concept. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 6 18:17:40 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07145 for ; Mon, 6 Dec 2004 18:17:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbS5p-0005Qm-03 for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 23:16:33 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CbS5n-0005QB-34 for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 23:16:31 +0000 Received: from cats-mx4.ucsc.edu ([128.114.125.37]) by bart.w3.org with esmtp (Exim 4.34) id 1CbS5m-00005n-RL for w3c-dist-auth@w3.org; Mon, 06 Dec 2004 23:16:31 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx4.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB6NB8Em019616; Mon, 6 Dec 2004 15:11:12 -0800 (PST) Message-Id: <200412062311.iB6NB8Em019616@cats-mx4.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Julian Reschke'" Cc: "'Stefan Eissing'" , "'WebDAV \(WebDAV WG\)'" Date: Mon, 6 Dec 2004 15:11:01 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41B4D8ED.3020401@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTb4JHjzgq0EcK8TJWABU2ZpyUiEQABZmSw X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/200412062311.iB6NB8Em019616@cats-mx4.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9148 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 23:16:33 +0000 Content-Transfer-Encoding: 7bit Julian writes: > So, for a set of bindings that are part of that cyclic graph, > which one is "causing" it? Ah, now I see what you and Stefan are getting at. The binding "causing" a loop can depend on the traversal through the graph. For a given DAV operation, there is an out, though, in that you have a starting node for the operation. Given this, the binding causing a loop is one that either: A) points to a resource already traversed (child loop) or B) points to a resource that is both on the path of the starting node, and has shorter pathlength than the starting node (parent loop) (Let's see how this flies -- I have a sneaking suspicion I'm forgetting some edge case). > IMHO it doesn't because it doesn't need to. As far as I can > tell, until we say something else, the standard semantics > apply (and as far as I can tell, it's clear what they define > in this case). But because of the existence of loopback bindings, and their ability to have an operation bleed out to the entire resource space of a server, its not clear that the standard semantics should apply here, and hence saying nothing is ambiguous. > As long as a server stops descending into a collection when > it detects that it has visited that collection before, there > doesn't seem to be an issue. We agree here. The problem comes when you visit a parent collection of the starting point of a Depth infinity lock. > IMHO deep locks on bind loops are an edge case, in particular > if the bind loop includes the namespare root (as in the > example we discussed). So, how do we distinguish between edge cases we should address in the specification, and edge cases we shouldn't? Being an "edge case" doesn't immediately translate to "don't have to deal with this." > Is there anybody how already supports both or plans to > support both and will *not* implement the standard RFC2518 > deep lock semantics? I could say that the Catacomb server plans on doing this, though frankly I still haven't made up my mind yet. > BTW, another thing to keep in mind is that you don't need the > BIND spec to create bind loops. Once you accept the existence > of multiple URIs to the same resource, and the fact that > these resources can be collections, a simple MOVE operation > can create a BIND loop. You seem to roughly have the following criteria for whether to include language in the bind specification: * specifically addresses behavior defined in the bind specification * is not behavior explicitly defined in another specification These are reasonable. I feel I've addressed them by noting: * The ability to create bind loops is made much easier by the existence of the BIND and REBIND operations. * The interaction of bind loops and locking is hence raised far more forcefully by the bind specification. Furthermore, there is some difference of opinion over what this interaction should be among people who are experts in the area (you, me, and Geoff). * It's not clear that the authors of 2518 clearly knew whether their containment model was broadly inclusion-containment-like, or referential-containment-like. Certainly the amount of thought we put into this particular case was close to zero, and 2518 reflects this. Since I feel I've made this case pretty well, I'd prefer that we focus our attention on the technical issue, that is, developing appropriate language for handling this feature interaction. We're writing essays over the inclusion of a page of text, tops. - Jim From w3c-dist-auth-request@w3.org Mon Dec 6 18:26:11 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07852 for ; Mon, 6 Dec 2004 18:26:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbSES-0008QE-5r for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Dec 2004 23:25:28 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CbSER-0008Pg-NG for w3c-dist-auth@listhub.w3.org; Mon, 06 Dec 2004 23:25:27 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CbSER-0002OO-G2 for w3c-dist-auth@w3c.org; Mon, 06 Dec 2004 23:25:27 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3c.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB6NPMaa016600 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Dec 2004 15:25:22 -0800 In-Reply-To: <41B4DB1B.7020605@gmx.de> References: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> <41B4A44C.8070803@gmx.de> <6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4BB03.7050505@gmx.de> <1EFA6E09-47C4-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4C72D.8060700@gmx.de> <666E83CC-47D2-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4DB1B.7020605@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1434CD54-47DE-11D9-A94C-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Webdav WG From: Lisa Dusseault Date: Mon, 6 Dec 2004 15:25:13 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/1434CD54-47DE-11D9-A94C-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9149 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Dec 2004 23:25:28 +0000 Content-Transfer-Encoding: 7bit On Dec 6, 2004, at 2:20 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >>> If it doesn't matter, why does RFC2518 say: >>> >>> "Although implicit in [RFC2068] and [RFC2396], any resource, >>> including collection resources, MAY be identified by more than one >>> URI. For example, a resource could be identified by multiple HTTP >>> URLs." >>> >>> (>> rfc2518.html#rfc.section.5.1.p.4>) and >>> >>> "A resource may be made available through more than one URI. However >>> locks apply to resources, not URIs. Therefore a LOCK request on a >>> resource MUST NOT succeed if can not be honored by all the URIs >>> through which the resource is addressable." >>> >> In this case it *does* matter to clients because it is detectable -- >> the behavior has concrete results, even if the client can't detect >> that there are multiple bindings. If a client is trying to allow the >> user to > > It's always detectable. For instance, if I submit a depth:0 LOCK > request to "/a", and a subsequent PROPFIND on the DAV:lockdiscovery > property of "/b" shows that it is locked by the same lock I just > created on "/a", I can conclude that both are the same resource. > > BIND makes it *easier* to detect sameness, but it doesn't introduce > any new concept. > Clever... so an observant client could detect that the same lock existed on two URLs so conclude they are bindings to the same resource (unless the server calculates the value for lockdiscovery on the fly and does something unlikely and weird with lock tokens). I still think that the bindings draft makes it far more likely that a client will try to detect whether two bindings are the same resource and behave differently if they are. For example, a client that is bindings-aware could try to speed up synchronization by using 'DAV:resource-id' and synchronizing only once per resource, rather than once per binding. The client could cache the 'DAV:acl' property (or any other live property) for offline use. If the client knows that all bindings will have the same value for 'DAV:acl' then it only needs to request that property once per resource. OTOH if the client knows that different bindings may have different values for 'DAV:acl' (or another live property) then the client must ask once for each binding. I also worry that it's not enough for us to say that dead properties MUST be the same value no matter which binding is addressed but live properties MAY vary. We don't have a reliable way for the client to tell which properties are dead and which are live. Still, I could live with that. Lisa From w3c-dist-auth-request@w3.org Mon Dec 6 22:40:46 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24887 for ; Mon, 6 Dec 2004 22:40:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbWC6-0005ZC-V5 for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Dec 2004 03:39:18 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CbWC4-0005YI-E4 for w3c-dist-auth@listhub.w3.org; Tue, 07 Dec 2004 03:39:16 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by bart.w3.org with esmtp (Exim 4.34) id 1CbWC4-0004Db-5a for w3c-dist-auth@w3.org; Tue, 07 Dec 2004 03:39:16 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB73civ5006721 for ; Mon, 6 Dec 2004 22:38:44 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB73ciOM099428 for ; Mon, 6 Dec 2004 22:38:44 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB73cinA001103 for ; Mon, 6 Dec 2004 22:38:44 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB73cisY001100 for ; Mon, 6 Dec 2004 22:38:44 -0500 In-Reply-To: <200412062311.iB6NB8Em019616@cats-mx4.ucsc.edu> To: "'WebDAV \(WebDAV WG\)'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 6 Dec 2004 22:38:47 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/06/2004 22:38:44, Serialize complete at 12/06/2004 22:38:44 Content-Type: multipart/alternative; boundary="=_alternative 001406CC85256F63_=" Received-SPF: none (bart.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/OFE23F5B5B.6540F515-ON85256F63.00106FEB-85256F63.001406CD@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9150 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Dec 2004 03:39:18 +0000 This is a multipart message in MIME format. --=_alternative 001406CC85256F63_= Content-Type: text/plain; charset="US-ASCII" Jim wrote on 12/06/2004 06:11:01 PM: > > Julian writes: > > > As far as I can > > tell, until we say something else, the standard semantics > > apply (and as far as I can tell, it's clear what they define > > in this case). > > But because of the existence of loopback bindings, and their ability to have > an operation bleed out to the entire resource space of a server, its not > clear that the standard semantics should apply here, and hence saying > nothing is ambiguous. I fail to understand your concern here. If a user places a lock on the root of the resource space, standard semantics apply and the whole resource tree is locked. If a user places a lock on a resource that has a binding path to the root of the resource space, standard semantics apply and the whole resource tree is locked. Why is the first OK and the second a problem that needs to be fixed? One can make just a good a case that the standard semantics is what is intended, so I see no compelling case for defining exceptional behavior here. In particular, the alternative semantics you describe are more complex, and likely to be computationally impractical to maintain as bindings are added and removed under a depth locked resource. > > As long as a server stops descending into a collection when > > it detects that it has visited that collection before, there > > doesn't seem to be an issue. > > We agree here. The problem comes when you visit a parent collection of the > starting point of a Depth infinity lock. I don't see why this is a problem. > > IMHO deep locks on bind loops are an edge case, in particular > > if the bind loop includes the namespare root (as in the > > example we discussed). > > So, how do we distinguish between edge cases we should address in the > specification, and edge cases we shouldn't? Being an "edge case" doesn't > immediately translate to "don't have to deal with this." If we decide that the standard semantics should apply to this case, then I believe that we should not single it out, just to say "the standard semantics apply here as well as everywhere else". > > Is there anybody how already supports both or plans to > > support both and will *not* implement the standard RFC2518 > > deep lock semantics? > > I could say that the Catacomb server plans on doing this, though frankly I > still haven't made up my mind yet. I'd be interested in the combinatorics/cost of maintaining the semantics you are suggesting when adding or removing bindings under a depth lock. In particular, turning an UNBIND/REBIND/BIND into an operation that takes time proportional to the number of members of the resource would be a bad thing. > > BTW, another thing to keep in mind is that you don't need the > > BIND spec to create bind loops. Once you accept the existence > > of multiple URIs to the same resource, and the fact that > > these resources can be collections, a simple MOVE operation > > can create a BIND loop. > > You seem to roughly have the following criteria for whether to include > language in the bind specification: > > * specifically addresses behavior defined in the bind specification > * is not behavior explicitly defined in another specification > > These are reasonable. I feel I've addressed them by noting: > > * The ability to create bind loops is made much easier by the existence of > the BIND and REBIND operations. Just because a spec makes an operation easier doesn't decrease the conflicts that arise when the spec defining that feature modifies the semantics, and the spec that "makes that feature easier" are not being maintained/released in lock step. > * The interaction of bind loops and locking is hence raised far more > forcefully by the bind specification. Furthermore, there is some difference > of opinion over what this interaction should be among people who are experts > in the area (you, me, and Geoff). Same response to "raising more forcefully". Doesn't change the spec interconnection problem introduced by defining the semantics of a feature in a different spec from the one that introduces it. > * It's not clear that the authors of 2518 clearly knew whether their > containment model was broadly inclusion-containment-like, or > referential-containment-like. Certainly the amount of thought we put into > this particular case was close to zero, and 2518 reflects this. Good thing that we're working on 2518bis then (:-). > Since I feel I've made this case pretty well, I'd prefer that we focus our > attention on the technical issue, that is, developing appropriate language > for handling this feature interaction. We're writing essays over the > inclusion of a page of text, tops. I agree. But I believe the standard semantics should apply in this case, so I believe no addition to the text is needed for it. Cheers, Geoff --=_alternative 001406CC85256F63_= Content-Type: text/html; charset="US-ASCII"
Jim wrote on 12/06/2004 06:11:01 PM:
>
> Julian writes:
>
> > As far as I can
> > tell, until we say something else, the standard semantics
> > apply (and as far as I can tell, it's clear what they define
> > in this case).
>
> But because of the existence of loopback bindings, and their ability to have
> an operation bleed out to the entire resource space of a server, its not
> clear that the standard semantics should apply here, and hence saying
> nothing is ambiguous.

I fail to understand your concern here.  If a user places a lock on
the root of the resource space, standard semantics apply and the whole
resource tree is locked.  If a user places a lock on a resource that
has a binding path to the root of the resource space, standard semantics
apply and the whole resource tree is locked.  Why is the first OK and
the second a problem that needs to be fixed?

One can make just a good a case that the standard semantics is what
is intended, so I see no compelling case for defining exceptional behavior
here.  In particular, the alternative semantics you describe are more
complex, and likely to be computationally impractical to maintain as
bindings are added and removed under a depth locked resource.

> > As long as a server stops descending into a collection when
> > it detects that it has visited that collection before, there
> > doesn't seem to be an issue.
>
> We agree here. The problem comes when you visit a parent collection of the
> starting point of a Depth infinity lock.

I don't see why this is a problem.

> > IMHO deep locks on bind loops are an edge case, in particular
> > if the bind loop includes the namespare root (as in the
> > example we discussed).
>
> So, how do we distinguish between edge cases we should address in the
> specification, and edge cases we shouldn't? Being an "edge case" doesn't
> immediately translate to "don't have to deal with this."

If we decide that the standard semantics should apply to this case,
then I believe that we should not single it out, just to say "the standard
semantics apply here as well as everywhere else".

> > Is there anybody how already supports both or plans to
> > support both and will *not* implement the standard RFC2518
> > deep lock semantics?
>
> I could say that the Catacomb server plans on doing this, though frankly I
> still haven't made up my mind yet.

I'd be interested in the combinatorics/cost of maintaining the semantics
you are suggesting when adding or removing bindings under a depth lock.
In particular, turning an UNBIND/REBIND/BIND into an operation that takes
time proportional to the number of members of the resource would be a
bad thing.
 
> > BTW, another thing to keep in mind is that you don't need the
> > BIND spec to create bind loops. Once you accept the existence
> > of multiple URIs to the same resource, and the fact that
> > these resources can be collections, a simple MOVE operation
> > can create a BIND loop.
>
> You seem to roughly have the following criteria for whether to include
> language in the bind specification:
>
> * specifically addresses behavior defined in the bind specification
> * is not behavior explicitly defined in another specification
>
> These are reasonable. I feel I've addressed them by noting:
>
> * The ability to create bind loops is made much easier by the existence of
> the BIND and REBIND operations.

Just because a spec makes an operation easier doesn't decrease the conflicts
that arise when the spec defining that feature modifies the semantics, and the
spec that "makes that feature easier" are not being maintained/released in
lock step.

> * The interaction of bind loops and locking is hence raised far more
> forcefully by the bind specification. Furthermore, there is some difference
> of opinion over what this interaction should be among people who are experts
> in the area (you, me, and Geoff).

Same response to "raising more forcefully".  Doesn't change the spec
interconnection problem introduced by defining the semantics of a feature
in a different spec from the one that introduces it.

> * It's not clear that the authors of 2518 clearly knew whether their
> containment model was broadly inclusion-containment-like, or
> referential-containment-like. Certainly the amount of thought we put into
> this particular case was close to zero, and 2518 reflects this.

Good thing that we're working on 2518bis then (:-).

> Since I feel I've made this case pretty well, I'd prefer that we focus our
> attention on the technical issue, that is, developing appropriate language
> for handling this feature interaction. We're writing essays over the
> inclusion of a page of text, tops.
I agree.  But I believe the standard semantics should apply in this case,
so I believe no addition to the text is needed for it.

Cheers,
Geoff

--=_alternative 001406CC85256F63_=-- From w3c-dist-auth-request@w3.org Tue Dec 7 02:29:59 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26686 for ; Tue, 7 Dec 2004 02:29:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbZlV-0001oM-37 for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Dec 2004 07:28:05 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CbZlT-0001n1-C1 for w3c-dist-auth@listhub.w3.org; Tue, 07 Dec 2004 07:28:03 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1CbZlS-0002ax-S3 for w3c-dist-auth@w3.org; Tue, 07 Dec 2004 07:28:03 +0000 Received: from [192.168.1.26] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.1.R) with ESMTP id md50000066416.msg for ; Tue, 07 Dec 2004 08:27:53 +0100 In-Reply-To: <200412062311.iB6NB8Em019616@cats-mx4.ucsc.edu> References: <200412062311.iB6NB8Em019616@cats-mx4.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7EA1830B-4821-11D9-8A53-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit Cc: "'Julian Reschke'" , "'WebDAV \(WebDAV WG\)'" From: Stefan Eissing Date: Tue, 7 Dec 2004 08:27:47 +0100 To: X-Mailer: Apple Mail (2.619) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Tue, 07 Dec 2004 08:27:53 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Received-SPF: none (bart.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/7EA1830B-4821-11D9-8A53-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9151 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Dec 2004 07:28:05 +0000 Content-Transfer-Encoding: 7bit If we can get a rough consensus on the expected behaviour of locks on circular binds, I'm all for putting it in the spec. If not, I think the spec should remain silent on the issue. Am 07.12.2004 um 00:11 schrieb Jim Whitehead: > Julian writes: > >> So, for a set of bindings that are part of that cyclic graph, >> which one is "causing" it? > > Ah, now I see what you and Stefan are getting at. The binding > "causing" a > loop can depend on the traversal through the graph. > > For a given DAV operation, there is an out, though, in that you have a > starting node for the operation. Given this, the binding causing a > loop is > one that either: > A) points to a resource already traversed (child loop) > or > B) points to a resource that is both on the path of the starting node, > and > has shorter pathlength than the starting node (parent loop) > > (Let's see how this flies -- I have a sneaking suspicion I'm > forgetting some > edge case). > >> IMHO it doesn't because it doesn't need to. As far as I can >> tell, until we say something else, the standard semantics >> apply (and as far as I can tell, it's clear what they define >> in this case). > > But because of the existence of loopback bindings, and their ability > to have > an operation bleed out to the entire resource space of a server, its > not > clear that the standard semantics should apply here, and hence saying > nothing is ambiguous. > >> As long as a server stops descending into a collection when >> it detects that it has visited that collection before, there >> doesn't seem to be an issue. > > We agree here. The problem comes when you visit a parent collection of > the > starting point of a Depth infinity lock. > >> IMHO deep locks on bind loops are an edge case, in particular >> if the bind loop includes the namespare root (as in the >> example we discussed). > > So, how do we distinguish between edge cases we should address in the > specification, and edge cases we shouldn't? Being an "edge case" > doesn't > immediately translate to "don't have to deal with this." > > >> Is there anybody how already supports both or plans to >> support both and will *not* implement the standard RFC2518 >> deep lock semantics? > > I could say that the Catacomb server plans on doing this, though > frankly I > still haven't made up my mind yet. > >> BTW, another thing to keep in mind is that you don't need the >> BIND spec to create bind loops. Once you accept the existence >> of multiple URIs to the same resource, and the fact that >> these resources can be collections, a simple MOVE operation >> can create a BIND loop. > > You seem to roughly have the following criteria for whether to include > language in the bind specification: > > * specifically addresses behavior defined in the bind specification > * is not behavior explicitly defined in another specification > > These are reasonable. I feel I've addressed them by noting: > > * The ability to create bind loops is made much easier by the > existence of > the BIND and REBIND operations. > > * The interaction of bind loops and locking is hence raised far more > forcefully by the bind specification. Furthermore, there is some > difference > of opinion over what this interaction should be among people who are > experts > in the area (you, me, and Geoff). > > * It's not clear that the authors of 2518 clearly knew whether their > containment model was broadly inclusion-containment-like, or > referential-containment-like. Certainly the amount of thought we put > into > this particular case was close to zero, and 2518 reflects this. > > Since I feel I've made this case pretty well, I'd prefer that we focus > our > attention on the technical issue, that is, developing appropriate > language > for handling this feature interaction. We're writing essays over the > inclusion of a page of text, tops. > > - Jim > > From w3c-dist-auth-request@w3.org Tue Dec 7 05:52:45 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12055 for ; Tue, 7 Dec 2004 05:52:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbcwM-0000l8-Ov for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Dec 2004 10:51:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbcwL-0000k5-18 for w3c-dist-auth@listhub.w3.org; Tue, 07 Dec 2004 10:51:29 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CbcwD-0003kQ-E4 for w3c-dist-auth@w3c.org; Tue, 07 Dec 2004 10:51:21 +0000 Received: (qmail 7523 invoked by uid 65534); 7 Dec 2004 10:50:55 -0000 Received: from p50825714.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.87.20) by mail.gmx.net (mp021) with SMTP; 07 Dec 2004 11:50:55 +0100 X-Authenticated: #1915285 Message-ID: <41B58B0D.1090603@gmx.de> Date: Tue, 07 Dec 2004 11:50:53 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Webdav WG References: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> <41B4A44C.8070803@gmx.de> <6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4BB03.7050505@gmx.de> <1EFA6E09-47C4-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4C72D.8060700@gmx.de> <666E83CC-47D2-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4DB1B.7020605@gmx.de> <1434CD54-47DE-11D9-A94C-000A95B2BB72@osafoundation.org> In-Reply-To: <1434CD54-47DE-11D9-A94C-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41B58B0D.1090603@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9152 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Dec 2004 10:51:30 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > On Dec 6, 2004, at 2:20 PM, Julian Reschke wrote: > ... > Clever... so an observant client could detect that the same lock > existed on two URLs so conclude they are bindings to the same resource > (unless the server calculates the value for lockdiscovery on the fly > and does something unlikely and weird with lock tokens). If a server does something "unlikely and weird" that causes this not to work, then it's broken. There's no reason to believe that a server that get's DAV:lockdiscovery wrong will get DAV:resource-id right, so why would I worry about that? > I still think that the bindings draft makes it far more likely that a > client will try to detect whether two bindings are the same resource > and behave differently if they are. For example, a client that is > bindings-aware could try to speed up synchronization by using > 'DAV:resource-id' and synchronizing only once per resource, rather than > once per binding. The client could cache the 'DAV:acl' property (or > any other live property) for offline use. If the client knows that all > bindings will have the same value for 'DAV:acl' then it only needs to > request that property once per resource. OTOH if the client knows that > different bindings may have different values for 'DAV:acl' (or another > live property) then the client must ask once for each binding. Which is exactly the reason why RFC3744 says that DAV:acl will be the same no matter what binding you use. > I also worry that it's not enough for us to say that dead properties > MUST be the same value no matter which binding is addressed but live > properties MAY vary. We don't have a reliable way for the client to > tell which properties are dead and which are live. Still, I could live > with that. Well, as you just pointed out, the difference between dead and live properties is fuzzy. Also, the statement as proposed, sort of *encourages* implementers to have live properties varying by binding. IMHO, they shouldn't (as properties are part of the state of the resource or computed based on the state of a resource), and thus should not vary at all. My impression from earlier discussion was that you don't buy that point of view, so I haven't tried hard to get it into the spec. Should I now? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 7 06:13:57 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13506 for ; Tue, 7 Dec 2004 06:13:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbdHG-00016B-Sh for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Dec 2004 11:13:06 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CbdHG-00015S-J0 for w3c-dist-auth@listhub.w3.org; Tue, 07 Dec 2004 11:13:06 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CbdHG-0002oB-8p for w3c-dist-auth@w3.org; Tue, 07 Dec 2004 11:13:06 +0000 Received: (qmail 12151 invoked by uid 65534); 7 Dec 2004 11:12:33 -0000 Received: from p50825714.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.87.20) by mail.gmx.net (mp022) with SMTP; 07 Dec 2004 12:12:33 +0100 X-Authenticated: #1915285 Message-ID: <41B59020.5070902@gmx.de> Date: Tue, 07 Dec 2004 12:12:32 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'Stefan Eissing'" , "'WebDAV (WebDAV WG)'" References: <200412062311.iB6NB8Em019616@cats-mx4.ucsc.edu> In-Reply-To: <200412062311.iB6NB8Em019616@cats-mx4.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/41B59020.5070902@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9153 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Dec 2004 11:13:06 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Julian writes: > > >>So, for a set of bindings that are part of that cyclic graph, >>which one is "causing" it? > > > Ah, now I see what you and Stefan are getting at. The binding "causing" a > loop can depend on the traversal through the graph. I'd rephrase slighty differently: given a cyclic graph caused by a set of bindings, there is no single binding "causing" it. Remove any of them, and the loop will be broken. > ... >>IMHO it doesn't because it doesn't need to. As far as I can >>tell, until we say something else, the standard semantics >>apply (and as far as I can tell, it's clear what they define >>in this case). > > > But because of the existence of loopback bindings, and their ability to have > an operation bleed out to the entire resource space of a server, its not > clear that the standard semantics should apply here, and hence saying > nothing is ambiguous. If a bind loop bleeds out to the entire resource space, it's because it includes the root collection. IMHO, this is definitively an edge case, and the base locking semantics should not be made more complex to take care of edge cases like this. With the removal of lock-null resources and the work on GULP (), we have achieved a really simple set of rules that fully define locks. Adding special cases here just for edge cases IMHO would be a step into the wrong direction. >>As long as a server stops descending into a collection when >>it detects that it has visited that collection before, there >>doesn't seem to be an issue. > > > We agree here. The problem comes when you visit a parent collection of the > starting point of a Depth infinity lock. I'm still not sure why you call that a "problem". As far as I can tell, it works exactly as designed. >>IMHO deep locks on bind loops are an edge case, in particular >>if the bind loop includes the namespare root (as in the >>example we discussed). > > > So, how do we distinguish between edge cases we should address in the > specification, and edge cases we shouldn't? Being an "edge case" doesn't > immediately translate to "don't have to deal with this." I'm not saying we're not dealing with it; what I'm saying is that because it is an edge case it doesn't need *special* treatment. Adding special treatment for this case makes the base locking semantics significanly more complex, and it's still unclear what that would buy us. >... >>BTW, another thing to keep in mind is that you don't need the >>BIND spec to create bind loops. Once you accept the existence >>of multiple URIs to the same resource, and the fact that >>these resources can be collections, a simple MOVE operation >>can create a BIND loop. > > > You seem to roughly have the following criteria for whether to include > language in the bind specification: > > * specifically addresses behavior defined in the bind specification > * is not behavior explicitly defined in another specification > > These are reasonable. I feel I've addressed them by noting: > > * The ability to create bind loops is made much easier by the existence of > the BIND and REBIND operations. > > * The interaction of bind loops and locking is hence raised far more > forcefully by the bind specification. Furthermore, there is some difference > of opinion over what this interaction should be among people who are experts > in the area (you, me, and Geoff). That's fine and why we are discussing it. As far as I can tell, Geoff and I argue that the base semantics are just fine, and that's why we don't need to say anything about ut. If you argue that we need special semantics, that's a change to the base locking semantics (no matter where we write those down), and thus certainly needs working group consensus. > * It's not clear that the authors of 2518 clearly knew whether their > containment model was broadly inclusion-containment-like, or > referential-containment-like. Certainly the amount of thought we put into > this particular case was close to zero, and 2518 reflects this. Yes. So let's fix it in RFC2518bis. > Since I feel I've made this case pretty well, I'd prefer that we focus our > attention on the technical issue, that is, developing appropriate language > for handling this feature interaction. We're writing essays over the > inclusion of a page of text, tops. As far as I can tell, we currently disagree fundamentally about what the desired semantics are. You seem to ask for a change of the locking semantics, while Geoff and I say that the base semantics are just fine. I think it's up to you to (a) make a proposal what the intended semantics should be (did I miss that?) and (b) try to get support in the working group for that change. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 7 07:38:30 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22071 for ; Tue, 7 Dec 2004 07:38:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cbeao-00016j-QZ for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Dec 2004 12:37:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cbean-000160-He for w3c-dist-auth@listhub.w3.org; Tue, 07 Dec 2004 12:37:21 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cbeag-0002YV-AU for w3c-dist-auth@w3.org; Tue, 07 Dec 2004 12:37:14 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB7CamGW011752 for ; Tue, 7 Dec 2004 07:36:48 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB7CamT2249480 for ; Tue, 7 Dec 2004 07:36:48 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB7CamJt009601 for ; Tue, 7 Dec 2004 07:36:48 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB7CalBM009595 for ; Tue, 7 Dec 2004 07:36:47 -0500 To: "'WebDAV \(WebDAV WG\)'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 7 Dec 2004 07:36:51 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/07/2004 07:36:47, Serialize complete at 12/07/2004 07:36:47 Content-Type: multipart/alternative; boundary="=_alternative 0045499E85256F63_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/OFFB73D58E.4F15D656-ON85256F63.00433734-85256F63.004549A2@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9154 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Dec 2004 12:37:22 +0000 This is a multipart message in MIME format. --=_alternative 0045499E85256F63_= Content-Type: text/plain; charset="US-ASCII" Geoff wrote on 12/06/2004 11:45:00 PM: > Jim wrote on 12/06/2004 06:11:01 PM: > > > > Julian writes: > > > > > Is there anybody how already supports both or plans to > > > support both and will *not* implement the standard RFC2518 > > > deep lock semantics? > > > > I could say that the Catacomb server plans on doing this, though frankly I > > still haven't made up my mind yet. > > I'd be interested in the combinatorics/cost of maintaining the semantics > you are suggesting when adding or removing bindings under a depth lock. > In particular, turning an UNBIND/REBIND/BIND into an operation that takes > time proportional to the number of members of the resource would be a > bad thing. I retract my concern about the combinatorics, since I believe a way to phrase Jim's proposal is that: "Suppose there is a depth lock, and: - there is one path to that resource is protected by that lock but the resource is not locked by that lock (because the resource is a parent of the locked resource along the path protected by the URL), and - there is another path to that resource that would lock the resource by that lock (because of a binding loop to that resource), then the semantics of the non-locking path applies (i.e. the path to the resource is protected by that lock but the resource is not locked by that lock). It is a little more complicated than this, because you have to make clear that the depth recursion is stopped at this point as well, but since a server must maintain both the protected and locked information, computing Jim's proposed semantics should be not much worse than computing information that is already required. But with all that said, I do not agree that this is the right semantics for this case, but rather believe that the default semantics is both simpler and more likely to be what the client had in mind for the depth lock. And if there is no consensus about what the semantics should be in this case, that is another reason to avoid saying anything about it in the binding spec. Cheers, Geoff --=_alternative 0045499E85256F63_= Content-Type: text/html; charset="US-ASCII"
Geoff wrote on 12/06/2004 11:45:00 PM:

> Jim wrote on 12/06/2004 06:11:01 PM:
> >
> > Julian writes:
> >
> > > Is there anybody how already supports both or plans to
> > > support both and will *not* implement the standard RFC2518
> > > deep lock semantics?
> >
> > I could say that the Catacomb server plans on doing this, though frankly I
> > still haven't made up my mind yet.
>
> I'd be interested in the combinatorics/cost of maintaining the semantics
> you are suggesting when adding or removing bindings under a depth lock.
> In particular, turning an UNBIND/REBIND/BIND into an operation that takes
> time proportional to the number of members of the resource would be a
> bad thing.

I retract my concern about the combinatorics, since I believe a way to
phrase Jim's proposal is that:

"Suppose there is a depth lock, and:
- there is one path to that resource is protected by that lock but
the resource is not locked by that lock (because the resource is
a parent of the locked resource along the path protected by the URL), and
- there is another path to that resource that would lock the resource
by that lock (because of a binding loop to that resource),
then the semantics of the non-locking path applies
(i.e. the path to the resource is protected by that lock
but the resource is not locked by that lock).

It is a little more complicated than this, because you have to make
clear that the depth recursion is stopped at this point as well,
but since a server must maintain both the protected and locked information,
computing Jim's proposed semantics should be not much worse than computing
information that is already required.

But with all that said, I do not agree that this is the right semantics
for this case, but rather believe that the default semantics is both simpler
and more likely to be what the client had in mind for the depth lock.

And if there is no consensus about what the semantics should be in this
case, that is another reason to avoid saying anything about it in the
binding spec.

Cheers,
Geoff





 


--=_alternative 0045499E85256F63_=-- From w3c-dist-auth-request@w3.org Tue Dec 7 12:47:39 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28899 for ; Tue, 7 Dec 2004 12:47:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbjP4-0003h7-37 for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Dec 2004 17:45:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbjP2-0003ff-Be for w3c-dist-auth@listhub.w3.org; Tue, 07 Dec 2004 17:45:32 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CbjOv-00019P-1d for w3c-dist-auth@w3c.org; Tue, 07 Dec 2004 17:45:25 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3c.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB7HjGaa026469 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 7 Dec 2004 09:45:17 -0800 In-Reply-To: <41B58B0D.1090603@gmx.de> References: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> <41B4A44C.8070803@gmx.de> <6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4BB03.7050505@gmx.de> <1EFA6E09-47C4-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4C72D.8060700@gmx.de> <666E83CC-47D2-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4DB1B.7020605@gmx.de> <1434CD54-47DE-11D9-A94C-000A95B2BB72@osafoundation.org> <41B58B0D.1090603@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Webdav WG From: Lisa Dusseault Date: Tue, 7 Dec 2004 09:45:07 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/BBC9849E-4877-11D9-80AA-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9155 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Dec 2004 17:45:34 +0000 Content-Transfer-Encoding: 7bit > >> I still think that the bindings draft makes it far more likely that a >> client will try to detect whether two bindings are the same resource >> and behave differently if they are. For example, a client that is >> bindings-aware could try to speed up synchronization by using >> 'DAV:resource-id' and synchronizing only once per resource, rather >> than once per binding. The client could cache the 'DAV:acl' >> property (or any other live property) for offline use. If the >> client knows that all bindings will have the same value for >> 'DAV:acl' then it only needs to request that property once per >> resource. OTOH if the client knows that different bindings may have >> different values for 'DAV:acl' (or another live property) then the >> client must ask once for each binding. > > Which is exactly the reason why RFC3744 says that DAV:acl will be the > same no matter what binding you use. I took 'DAV:acl' as an example because it's one we're familiar with and we can see the consequences of error. It's other live properties I'm worried about. (BTW, where does RFC3744 say that? I see lots of places where 'DAV:acl' is defined with respect to a resource and the language is fairly precise about resources and URLs, so one might believe that this behavior is implicit, but I can't see where it says anything about bindings.) > >> I also worry that it's not enough for us to say that dead properties >> MUST be the same value no matter which binding is addressed but live >> properties MAY vary. We don't have a reliable way for the client to >> tell which properties are dead and which are live. Still, I could >> live with that. > > Well, as you just pointed out, the difference between dead and live > properties is fuzzy. Also, the statement as proposed, sort of > *encourages* implementers to have live properties varying by binding. > IMHO, they shouldn't (as properties are part of the state of the > resource or computed based on the state of a resource), and thus > should not vary at all. My impression from earlier discussion was that > you don't buy that point of view, so I haven't tried hard to get it > into the spec. Should I now? > Even if I disagree with the conclusion -- perhaps *particularly* because I disagree with the conclusion and others may also -- I feel strongly that the decision should be reflected as a requirement in the specification. Lisa From w3c-dist-auth-request@w3.org Tue Dec 7 13:02:01 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00232 for ; Tue, 7 Dec 2004 13:02:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cbjdr-0007x9-11 for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Dec 2004 18:00:51 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cbjdq-0007wT-MX for w3c-dist-auth@listhub.w3.org; Tue, 07 Dec 2004 18:00:50 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cbjdq-0004aR-C9 for w3c-dist-auth@w3c.org; Tue, 07 Dec 2004 18:00:50 +0000 Received: (qmail 13190 invoked by uid 65534); 7 Dec 2004 18:00:00 -0000 Received: from p5082559C.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.85.156) by mail.gmx.net (mp009) with SMTP; 07 Dec 2004 19:00:00 +0100 X-Authenticated: #1915285 Message-ID: <41B5EF9F.90401@gmx.de> Date: Tue, 07 Dec 2004 18:59:59 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Webdav WG References: <200412060239.iB62dNaq017075@ietf.cse.ucsc.edu> <41B4A44C.8070803@gmx.de> <6D75A8FE-47B8-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4BB03.7050505@gmx.de> <1EFA6E09-47C4-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4C72D.8060700@gmx.de> <666E83CC-47D2-11D9-A94C-000A95B2BB72@osafoundation.org> <41B4DB1B.7020605@gmx.de> <1434CD54-47DE-11D9-A94C-000A95B2BB72@osafoundation.org> <41B58B0D.1090603@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41B5EF9F.90401@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9156 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Dec 2004 18:00:51 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I took 'DAV:acl' as an example because it's one we're familiar with and > we can see the consequences of error. It's other live properties I'm > worried about. > (BTW, where does RFC3744 say that? I see lots of places where 'DAV:acl' > is defined with respect to a resource and the language is fairly precise > about resources and URLs, so one might believe that this behavior is > implicit, but I can't see where it says anything about bindings.) It doesn't need to: >>> I also worry that it's not enough for us to say that dead properties >>> MUST be the same value no matter which binding is addressed but live >>> properties MAY vary. We don't have a reliable way for the client to >>> tell which properties are dead and which are live. Still, I could >>> live with that. >> >> >> Well, as you just pointed out, the difference between dead and live >> properties is fuzzy. Also, the statement as proposed, sort of >> *encourages* implementers to have live properties varying by binding. >> IMHO, they shouldn't (as properties are part of the state of the >> resource or computed based on the state of a resource), and thus >> should not vary at all. My impression from earlier discussion was that >> you don't buy that point of view, so I haven't tried hard to get it >> into the spec. Should I now? >> > Even if I disagree with the conclusion -- perhaps *particularly* because > I disagree with the conclusion and others may also -- I feel strongly > that the decision should be reflected as a requirement in the > specification. However, that requires that there *is* a decision. As far as I can tell, there's currently no consensus for any specific statement. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 7 13:28:12 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03245 for ; Tue, 7 Dec 2004 13:28:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cbk3X-0004ol-70 for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Dec 2004 18:27:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cbk3W-0004nH-Ur for w3c-dist-auth@listhub.w3.org; Tue, 07 Dec 2004 18:27:22 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cbk3P-0001ND-Hx for w3c-dist-auth@w3.org; Tue, 07 Dec 2004 18:27:15 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB7IQpv5025500 for ; Tue, 7 Dec 2004 13:26:51 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB7IQoT2259952 for ; Tue, 7 Dec 2004 13:26:50 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB7IQoNT003945 for ; Tue, 7 Dec 2004 13:26:50 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB7IQojW003939 for ; Tue, 7 Dec 2004 13:26:50 -0500 In-Reply-To: <41B5EF9F.90401@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 7 Dec 2004 13:26:53 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/07/2004 13:26:50, Serialize complete at 12/07/2004 13:26:50 Content-Type: multipart/alternative; boundary="=_alternative 0065559185256F63_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/OFBB5E5C42.22982958-ON85256F63.006489F1-85256F63.00655592@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9157 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Dec 2004 18:27:23 +0000 This is a multipart message in MIME format. --=_alternative 0065559185256F63_= Content-Type: text/plain; charset="US-ASCII" Julian wrote on 12/07/2004 12:59:59 PM: > Lisa Dusseault wrote: > > Even if I disagree with the conclusion -- perhaps *particularly* because > > I disagree with the conclusion and others may also -- I feel strongly > > that the decision should be reflected as a requirement in the > > specification. > > However, that requires that there *is* a decision. As far as I can tell, > there's currently no consensus for any specific statement. I agree (that there is no consensus ... I am undecided about this myself since there are valid arguments to be made in either direction). So in this case, since the core bind functionality does not depend on having an answer to this question, we should leave the issue unspecified, so that client do not false assume that this behavior is standarized. When we have reached consensus on this point, we can add it to the next revision of the appropriate specification (and at that time, can reopen the debate on which is the appropriate specification :-). Cheers, Geoff --=_alternative 0065559185256F63_= Content-Type: text/html; charset="US-ASCII"
Julian wrote on 12/07/2004 12:59:59 PM:

> Lisa Dusseault wrote:
> > Even if I disagree with the conclusion -- perhaps *particularly* because
> > I disagree with the conclusion and others may also -- I feel strongly
> > that the decision should be reflected as a requirement in the
> > specification.
>
> However, that requires that there *is* a decision. As far as I can tell,
> there's currently no consensus for any specific statement.
I agree (that there is no consensus ... I am undecided about this myself
since there are valid arguments to be made in either direction).

So in this case, since the core bind functionality does not depend on
having an answer to this question, we should leave the issue unspecified,
so that client do not false assume that this behavior is standarized.
When we have reached consensus on this point, we can add it to the next
revision of the appropriate specification (and at that time, can reopen
the debate on which is the appropriate specification :-).

Cheers,
Geoff
--=_alternative 0065559185256F63_=-- From w3c-dist-auth-request@w3.org Tue Dec 7 19:17:59 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19394 for ; Tue, 7 Dec 2004 19:17:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CbpV9-0001Ew-12 for w3c-dist-auth-dist@listhub.w3.org; Wed, 08 Dec 2004 00:16:15 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CbpV7-0001EH-Ap for w3c-dist-auth@listhub.w3.org; Wed, 08 Dec 2004 00:16:13 +0000 Received: from cats-mx4.ucsc.edu ([128.114.125.37]) by lisa.w3.org with esmtp (Exim 4.34) id 1CbpUz-0004Kk-70 for w3c-dist-auth@w3.org; Wed, 08 Dec 2004 00:16:05 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx4.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB80FWsp016173 for ; Tue, 7 Dec 2004 16:15:36 -0800 (PST) Message-Id: <200412080015.iB80FWsp016173@cats-mx4.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'webdav'" Date: Tue, 7 Dec 2004 16:15:24 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTcinDXUbkK1WvYQ0GZSCzkOga92AAMFL7w X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/200412080015.iB80FWsp016173@cats-mx4.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9158 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 08 Dec 2004 00:16:15 +0000 Content-Transfer-Encoding: 7bit Seems to me we already have an example of a live property that varies depending on the binding used to access it -- DAV:displayname. On servers where this just reflects the binding name of the resource, it seems like it would vary depending on the binding used to access it. - Jim From w3c-dist-auth-request@w3.org Tue Dec 7 19:38:23 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21540 for ; Tue, 7 Dec 2004 19:38:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cbppt-0007qF-42 for w3c-dist-auth-dist@listhub.w3.org; Wed, 08 Dec 2004 00:37:41 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cbppr-0007pZ-Ex for w3c-dist-auth@listhub.w3.org; Wed, 08 Dec 2004 00:37:39 +0000 Received: from cats-mx2.ucsc.edu ([128.114.125.35]) by bart.w3.org with esmtp (Exim 4.34) id 1Cbppr-0002U0-7T for w3c-dist-auth@w3.org; Wed, 08 Dec 2004 00:37:39 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx2.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB80WtL9027015 for ; Tue, 7 Dec 2004 16:32:58 -0800 (PST) Message-Id: <200412080032.iB80WtL9027015@cats-mx2.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Tue, 7 Dec 2004 16:32:47 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41B59020.5070902@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTcTcdysL41IvzkRkCOcGSO8A0z4QAbWOZw X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/200412080032.iB80WtL9027015@cats-mx2.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9159 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 08 Dec 2004 00:37:41 +0000 Content-Transfer-Encoding: 7bit > I'm still not sure why you call that a "problem". As far as I > can tell, it works exactly as designed. Here is a plausible scenario that outlines why I think this is a problem. Assume there is a collection hierarchy rooted at a collection with non-unique pathname /collA/collB/collC/collD. Within this hierarchy there is one loopback binding to /collB/, one of approximately 500 bindings within the collD hierarchy. There is only the one loopback binding in the entire collD hierarchy. Alice wants to work on the /collA/collB/collC/collD hierarchy, and wants to ensure she can make changes to multiple documents to ensure their contents are consistent with one another. (Alice should probably be using DeltaV workspaces for this, but that's another matter). So, Alice depth locks the entire hierarchy, by submitting her lock request to /collA/collB/collC/collD. Bob knows that Alice is working on /collA/collB/collC/collD because they talked about her doing so at their staff meeting in the morning. So, he was surprised to discover that the area where he was supposed to work, /collA/collB/collE/collF, is locked by Alice. Bob phoned Alice and asked her why she had locked his work area, and Alice replied that she hadn't, and was confused as to why Bob thought this. Bob replied that his authoring tool reported her as owning the locks on those resources, and that she had locked his entire resource space. Alice uses WebDAV Explorer to unlock /collA/collB/collE/collF (good thing DAV Explorer automatically retrieves and applies the lock token it finds in the lockdiscovery header, otherwise Bob and Alice would really have a hard time :-) However, she's then confused as to why the locks on her resource space have disappeared. So she locks /collA/collB/collC/collD, only to find out that she can't take out the lock anymore. Frustrating. She asks Bob if he was able to take out a lock. Yes, he says, now I'm able to take out the lock and work. Strange, thinks Alice, it's as if the system only allows one of us to work at a time. Not understanding what is going on, and have received no error messages from her software that would lead her to think that a loopback binding is causing the problem, she calls her firm's technical support. Since most existing hierarchy browsers for WebDAV do not give any visibility into loopback bindings, it's anyone's guess as to how long it will take technical support to determine the root cause of the problem. - Jim From w3c-dist-auth-request@w3.org Tue Dec 7 21:59:10 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04567 for ; Tue, 7 Dec 2004 21:59:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cbs1h-0006Wf-KS for w3c-dist-auth-dist@listhub.w3.org; Wed, 08 Dec 2004 02:58:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cbs1f-0006Vw-UA for w3c-dist-auth@listhub.w3.org; Wed, 08 Dec 2004 02:57:59 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cbs1Y-0002GV-IX for w3c-dist-auth@w3.org; Wed, 08 Dec 2004 02:57:52 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB82vQBX001464 for ; Tue, 7 Dec 2004 21:57:26 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB82vQtL268878 for ; Tue, 7 Dec 2004 21:57:26 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB82vQKf022073 for ; Tue, 7 Dec 2004 21:57:26 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB82vQaw022066 for ; Tue, 7 Dec 2004 21:57:26 -0500 In-Reply-To: <200412080032.iB80WtL9027015@cats-mx2.ucsc.edu> To: "'WebDAV \(WebDAV WG\)'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 7 Dec 2004 21:57:24 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/07/2004 21:57:26, Serialize complete at 12/07/2004 21:57:26 Content-Type: multipart/alternative; boundary="=_alternative 00103EF585256F64_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/OF5FA1FA66.65F08A03-ON85256F64.000EBCD0-85256F64.00103EF6@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9160 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 08 Dec 2004 02:58:01 +0000 This is a multipart message in MIME format. --=_alternative 00103EF585256F64_= Content-Type: text/plain; charset="US-ASCII" The major reason to not change standard behavior in the way Jim suggests is that this will break existing clients. In particular, if a user depth locks a collection, a standard depth locking client will assume that the lock token will apply to all the members of that collection, and will pass that lock token in any edit request the user makes to a member of that collection. But with the semantics that Jim suggests, some of those members will remain mysteriously unlocked, and the editor just fails with "unexpectedly missing lock" when the user attempts to edit (or even worse, allows the user to edit an unlocked resource, without overwrite protection). Now let's contrast this with the scenario Jim describes. Surely any server that is bold enough to support both binding loops and depth locking would support the DAV:lockroot property introduced a while ago to solve exactly this problem of not knowing where a lock comes from. This means that neither Bob nor Alice is ever surprised or mystified about an "unexpected lock", because the DAV:lockroot says exactly where it came from. And if they want to discover the path back to the lock root, they just use the parent-bindings property to walk back through the locked parents until they find the root (or if they have a civilized client, their client will do this walk for them, and report the path from the lock root to the locked resource). So "overlocking" is always easily explained, and is the expected behavior for existing clients, while "underlocking" is both mysterious (how does a user use a standard client to discover why the member isn't locked?) and more significantly, will break existing clients that expect the standard depth locking behavior. Cheers, Geoff Jim wrote on 12/07/2004 07:32:47 PM: > > > I'm still not sure why you call that a "problem". As far as I > > can tell, it works exactly as designed. > > Here is a plausible scenario that outlines why I think this is a problem. > > Assume there is a collection hierarchy rooted at a collection with > non-unique pathname /collA/collB/collC/collD. Within this hierarchy there is > one loopback binding to /collB/, one of approximately 500 bindings within > the collD hierarchy. There is only the one loopback binding in the entire > collD hierarchy. > > Alice wants to work on the /collA/collB/collC/collD hierarchy, and wants to > ensure she can make changes to multiple documents to ensure their contents > are consistent with one another. (Alice should probably be using DeltaV > workspaces for this, but that's another matter). So, Alice depth locks the > entire hierarchy, by submitting her lock request to > /collA/collB/collC/collD. > > Bob knows that Alice is working on /collA/collB/collC/collD because they > talked about her doing so at their staff meeting in the morning. So, he was > surprised to discover that the area where he was supposed to work, > /collA/collB/collE/collF, is locked by Alice. Bob phoned Alice and asked her > why she had locked his work area, and Alice replied that she hadn't, and was > confused as to why Bob thought this. Bob replied that his authoring tool > reported her as owning the locks on those resources, and that she had locked > his entire resource space. > > Alice uses WebDAV Explorer to unlock /collA/collB/collE/collF (good thing > DAV Explorer automatically retrieves and applies the lock token it finds in > the lockdiscovery header, otherwise Bob and Alice would really have a hard > time :-) However, she's then confused as to why the locks on her resource > space have disappeared. So she locks /collA/collB/collC/collD, only to find > out that she can't take out the lock anymore. Frustrating. She asks Bob if > he was able to take out a lock. Yes, he says, now I'm able to take out the > lock and work. > > Strange, thinks Alice, it's as if the system only allows one of us to work > at a time. Not understanding what is going on, and have received no error > messages from her software that would lead her to think that a loopback > binding is causing the problem, she calls her firm's technical support. > Since most existing hierarchy browsers for WebDAV do not give any visibility > into loopback bindings, it's anyone's guess as to how long it will take > technical support to determine the root cause of the problem. > > - Jim > > --=_alternative 00103EF585256F64_= Content-Type: text/html; charset="US-ASCII"
The major reason to not change standard behavior in the way Jim suggests
is that this will break existing clients.  In particular, if a user depth
locks a collection, a standard depth locking client will assume that the
lock token will apply to all the members of that collection, and will pass
that lock token in any edit request the user makes to a member of that
collection.

But with the semantics that Jim suggests, some of those members will remain
mysteriously unlocked, and the editor just fails with "unexpectedly missing
lock" when the user attempts to edit (or even worse, allows the user to edit
an unlocked resource, without overwrite protection).

Now let's contrast this with the scenario Jim describes.  Surely any server
that is bold enough to support both binding loops and depth locking would
support the DAV:lockroot property introduced a while ago to solve exactly
this problem of not knowing where a lock comes from.  This means that
neither Bob nor Alice is ever surprised or mystified about an "unexpected
lock", because the DAV:lockroot says exactly where it came from.  And if
they want to discover the path back to the lock root, they just use the
parent-bindings property to walk back through the locked parents until they
find the root (or if they have a civilized client, their client will do this
walk for them, and report the path from the lock root to the locked resource).

So "overlocking" is always easily explained, and is the expected behavior
for existing clients, while "underlocking" is both mysterious (how does a
user use a standard client to discover why the member isn't locked?) and more
significantly, will break existing clients that expect the standard depth
locking behavior.

Cheers,
Geoff

Jim wrote on 12/07/2004 07:32:47 PM:

>
> > I'm still not sure why you call that a "problem". As far as I
> > can tell, it works exactly as designed.
>
> Here is a plausible scenario that outlines why I think this is a problem.
>
> Assume there is a collection hierarchy rooted at a collection with
> non-unique pathname /collA/collB/collC/collD. Within this hierarchy there is
> one loopback binding to /collB/, one of approximately 500 bindings within
> the collD hierarchy. There is only the one loopback binding in the entire
> collD hierarchy.
>
> Alice wants to work on the /collA/collB/collC/collD hierarchy, and wants to
> ensure she can make changes to multiple documents to ensure their contents
> are consistent with one another. (Alice should probably be using DeltaV
> workspaces for this, but that's another matter). So, Alice depth locks the
> entire hierarchy, by submitting her lock request to
> /collA/collB/collC/collD.
>
> Bob knows that Alice is working on /collA/collB/collC/collD because they
> talked about her doing so at their staff meeting in the morning. So, he was
> surprised to discover that the area where he was supposed to work,
> /collA/collB/collE/collF, is locked by Alice. Bob phoned Alice and asked her
> why she had locked his work area, and Alice replied that she hadn't, and was
> confused as to why Bob thought this. Bob replied that his authoring tool
> reported her as owning the locks on those resources, and that she had locked
> his entire resource space.
>
> Alice uses WebDAV Explorer to unlock /collA/collB/collE/collF (good thing
> DAV Explorer automatically retrieves and applies the lock token it finds in
> the lockdiscovery header, otherwise Bob and Alice would really have a hard
> time :-) However, she's then confused as to why the locks on her resource
> space have disappeared. So she locks /collA/collB/collC/collD, only to find
> out that she can't take out the lock anymore. Frustrating. She asks Bob if
> he was able to take out a lock. Yes, he says, now I'm able to take out the
> lock and work.
>
> Strange, thinks Alice, it's as if the system only allows one of us to work
> at a time. Not understanding what is going on, and have received no error
> messages from her software that would lead her to think that a loopback
> binding is causing the problem, she calls her firm's technical support.
> Since most existing hierarchy browsers for WebDAV do not give any visibility
> into loopback bindings, it's anyone's guess as to how long it will take
> technical support to determine the root cause of the problem.
>
> - Jim
>
>
--=_alternative 00103EF585256F64_=-- From w3c-dist-auth-request@w3.org Wed Dec 8 09:01:02 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25869 for ; Wed, 8 Dec 2004 09:01:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cc2Kv-0006tK-7N for w3c-dist-auth-dist@listhub.w3.org; Wed, 08 Dec 2004 13:58:33 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cc2Kt-0006sg-Av for w3c-dist-auth@listhub.w3.org; Wed, 08 Dec 2004 13:58:31 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1Cc2Ks-0004Uc-Mw for w3c-dist-auth@w3.org; Wed, 08 Dec 2004 13:58:30 +0000 Received: (qmail 6035 invoked by uid 65534); 8 Dec 2004 13:57:57 -0000 Received: from p5082559C.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.85.156) by mail.gmx.net (mp026) with SMTP; 08 Dec 2004 14:57:57 +0100 X-Authenticated: #1915285 Message-ID: <41B70863.2030007@gmx.de> Date: Wed, 08 Dec 2004 14:57:55 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'webdav'" References: <200412080015.iB80FWsp016173@cats-mx4.ucsc.edu> In-Reply-To: <200412080015.iB80FWsp016173@cats-mx4.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41B70863.2030007@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9161 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 08 Dec 2004 13:58:33 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Seems to me we already have an example of a live property that varies > depending on the binding used to access it -- DAV:displayname. On servers > where this just reflects the binding name of the resource, it seems like it > would vary depending on the binding used to access it. This is a known issue with servers that indeed implement DAV:displayname that way; for instance discussed in . My position is, that a server that implements DAV:displayname as computed property based on the binding name is simply poorly implemented; DAV:displayname is defined to be "...a description of the resource that is suitable for presentation to a user" (), not a repetition of the last path segment. Apache/moddav and many other serves get this right; and I expect the same will apply to any server that actually supports multiple bindings. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Dec 8 09:42:51 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00339 for ; Wed, 8 Dec 2004 09:42:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cc30v-0004Ve-1h for w3c-dist-auth-dist@listhub.w3.org; Wed, 08 Dec 2004 14:41:57 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cc30u-0004V0-Jz for w3c-dist-auth@listhub.w3.org; Wed, 08 Dec 2004 14:41:56 +0000 Received: from imf23aec.mail.bellsouth.net ([205.152.59.71]) by bart.w3.org with esmtp (Exim 4.34) id 1Cc30u-00068b-F3 for w3c-dist-auth@w3.org; Wed, 08 Dec 2004 14:41:56 +0000 Received: from youre1aiymr7ts ([67.33.218.44]) by imf23aec.mail.bellsouth.net (InterMail vM.5.01.06.11 201-253-122-130-111-20040605) with SMTP id <20041208144125.FFNZ2382.imf23aec.mail.bellsouth.net@youre1aiymr7ts> for ; Wed, 8 Dec 2004 09:41:25 -0500 Message-ID: <000801c4dd34$00dda4a0$6101a8c0@youre1aiymr7ts> From: "Betty D Smith" To: Date: Wed, 8 Dec 2004 08:41:26 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C4DD01.B4B03890" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Received-SPF: pass (bart.w3.org: domain of walterabettyd@bellsouth.net designates 205.152.59.71 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: unempl claim mishandled X-Archived-At: http://www.w3.org/mid/000801c4dd34$00dda4a0$6101a8c0@youre1aiymr7ts Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9162 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 08 Dec 2004 14:41:57 +0000 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C4DD01.B4B03890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable how do i get NO office to quit giving me the run around about unempl = claim sent to them 11/05/2004...today lady there says ser rep has to = take walk ins and cannot call me...i talked to him mon. and he did not = call back like he said can we file claim direct to VA and will they take copies...original dr. = signature went to DAV Walter A Smith ------=_NextPart_000_0005_01C4DD01.B4B03890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
how do i get NO office to quit giving = me the run=20 around about unempl claim  sent to them 11/05/2004...today lady = there says=20 ser rep has to take walk ins and cannot call me...i talked to him mon. = and he=20 did not call back like he said
 
can we file claim direct to VA and will = they take=20 copies...original dr. signature went to DAV
 
Walter A = Smith
------=_NextPart_000_0005_01C4DD01.B4B03890-- From w3c-dist-auth-request@w3.org Wed Dec 8 19:02:45 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27535 for ; Wed, 8 Dec 2004 19:02:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcBk3-0000BJ-KU for w3c-dist-auth-dist@listhub.w3.org; Thu, 09 Dec 2004 00:01:07 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CcBk1-00008x-DR for w3c-dist-auth@listhub.w3.org; Thu, 09 Dec 2004 00:01:05 +0000 Received: from cats-mx1.ucsc.edu ([128.114.125.34]) by bart.w3.org with esmtp (Exim 4.34) id 1CcBk1-0004OZ-61 for w3c-dist-auth@w3.org; Thu, 09 Dec 2004 00:01:05 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx1.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB900C74000213 for ; Wed, 8 Dec 2004 16:00:15 -0800 (PST) Message-Id: <200412090000.iB900C74000213@cats-mx1.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Wed, 8 Dec 2004 16:00:01 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTc0dJvDtzFIVUiROivIsDaF0E+GgArzhtA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/200412090000.iB900C74000213@cats-mx1.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9163 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 09 Dec 2004 00:01:07 +0000 Content-Transfer-Encoding: 7bit Geoff Clemm writes: > But with the semantics that Jim suggests, some of those members will remain > mysteriously unlocked, and the editor just fails with "unexpectedly missing > lock" when the user attempts to edit (or even worse, allows the user to edit > an unlocked resource, without overwrite protection). and > Surely any server > that is bold enough to support both binding loops and depth locking would > support the DAV:lockroot property introduced a while ago to solve exactly > this problem of not knowing where a lock comes from. These are good points. That, plus the fact that I'm getting nowhere in convincing anyone else to change the semantics of loopback bindings, leads me to concede this point. It's now fine with me not to include any additional language in the BIND specification about locks and lookback bindings. - Jim From w3c-dist-auth-request@w3.org Wed Dec 8 19:14:05 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28390 for ; Wed, 8 Dec 2004 19:14:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcBvt-0005AV-Gf for w3c-dist-auth-dist@listhub.w3.org; Thu, 09 Dec 2004 00:13:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CcBvt-00059w-4g for w3c-dist-auth@listhub.w3.org; Thu, 09 Dec 2004 00:13:21 +0000 Received: from cats-mx4.ucsc.edu ([128.114.125.37]) by lisa.w3.org with esmtp (Exim 4.34) id 1CcBvl-0007vD-D4 for w3c-dist-auth@w3.org; Thu, 09 Dec 2004 00:13:13 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx4.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB90CZKX014846 for ; Wed, 8 Dec 2004 16:12:38 -0800 (PST) Message-Id: <200412090012.iB90CZKX014846@cats-mx4.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'webdav'" Date: Wed, 8 Dec 2004 16:12:23 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTcinDXUbkK1WvYQ0GZSCzkOga92AA9+JTA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/200412090012.iB90CZKX014846@cats-mx4.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9164 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 09 Dec 2004 00:13:21 +0000 Content-Transfer-Encoding: 7bit It seems to me that a live property inherently has the quality that its output can depend on an arbitrary computational process, which can make use of any aspect of the server's state it has access to. This includes bindings. While it is reasonable for servers to make use of this capability sparingly, it's also reasonable for them to have live properties that depend on binding state if it supports a particular application. Julian writes: > Also, the statement as proposed, sort of > *encourages* implementers to have live properties > varying by binding. IMHO, they shouldn't (as > properties are part of the state of the resource > or computed based on the state of a resource), and > thus should not vary at all. There's nothing in 2518 that implies a live property's computation depends only on the state of the resource. It would be prefectly valid to have a live property that returned a random number. I'm not too worried about encouraging binding-specific properties, as I believe implementors would be able to see the potential usability drawbacks of such properties. - Jim From w3c-dist-auth-request@w3.org Wed Dec 8 19:21:04 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28861 for ; Wed, 8 Dec 2004 19:21:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcC2g-0007NL-7O for w3c-dist-auth-dist@listhub.w3.org; Thu, 09 Dec 2004 00:20:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CcC2f-0007Lo-Nw for w3c-dist-auth@listhub.w3.org; Thu, 09 Dec 2004 00:20:21 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CcC2Y-00018q-8a for w3c-dist-auth@w3.org; Thu, 09 Dec 2004 00:20:14 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iB90KFaa014854 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 8 Dec 2004 16:20:18 -0800 In-Reply-To: <200412090000.iB900C74000213@cats-mx1.ucsc.edu> References: <200412090000.iB900C74000213@cats-mx1.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <167E48B5-4978-11D9-AC43-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: "'WebDAV \(WebDAV WG\)'" From: Lisa Dusseault Date: Wed, 8 Dec 2004 16:20:10 -0800 To: X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/167E48B5-4978-11D9-AC43-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9165 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 09 Dec 2004 00:20:22 +0000 Content-Transfer-Encoding: 7bit Sorry I've been a spectator on this one as well. I am uncomfortable about allowing loopback bindings at all, but I'm not sure what would improve the situation -- forbidding loopback bindings, fixing the lock interactions, or just letting server implementors sort things out. lisa On Dec 8, 2004, at 4:00 PM, Jim Whitehead wrote: > > Geoff Clemm writes: > >> But with the semantics that Jim suggests, some of those members will > remain >> mysteriously unlocked, and the editor just fails with "unexpectedly > missing >> lock" when the user attempts to edit (or even worse, allows the user >> to > edit >> an unlocked resource, without overwrite protection). > > and > >> Surely any server >> that is bold enough to support both binding loops and depth locking >> would >> support the DAV:lockroot property introduced a while ago to solve >> exactly >> this problem of not knowing where a lock comes from. > > These are good points. > > That, plus the fact that I'm getting nowhere in convincing anyone else > to > change the semantics of loopback bindings, leads me to concede this > point. > > It's now fine with me not to include any additional language in the > BIND > specification about locks and lookback bindings. > > - Jim > > From w3c-dist-auth-request@w3.org Thu Dec 9 14:59:41 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27002 for ; Thu, 9 Dec 2004 14:59:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcUOq-0005Zw-8E for w3c-dist-auth-dist@listhub.w3.org; Thu, 09 Dec 2004 19:56:28 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CcUOo-0005Yh-IW for w3c-dist-auth@listhub.w3.org; Thu, 09 Dec 2004 19:56:26 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CcUOn-0008B3-R1 for w3c-dist-auth@w3.org; Thu, 09 Dec 2004 19:56:26 +0000 Received: (qmail 21443 invoked by uid 65534); 9 Dec 2004 19:55:51 -0000 Received: from p54856FE9.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.111.233) by mail.gmx.net (mp014) with SMTP; 09 Dec 2004 20:55:51 +0100 X-Authenticated: #1915285 Message-ID: <41B8ADBB.2070504@gmx.de> Date: Thu, 09 Dec 2004 20:55:39 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412090000.iB900C74000213@cats-mx1.ucsc.edu> In-Reply-To: <200412090000.iB900C74000213@cats-mx1.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Locks and loopback bindings X-Archived-At: http://www.w3.org/mid/41B8ADBB.2070504@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9166 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 09 Dec 2004 19:56:28 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > ... > These are good points. > > That, plus the fact that I'm getting nowhere in convincing anyone else to > change the semantics of loopback bindings, leads me to concede this point. > > It's now fine with me not to include any additional language in the BIND > specification about locks and lookback bindings. OK, for purposes of tracking, I've added both issue and resolution to the document, see . As far I can tell, the only other open discussion we have is about the behaviour of properties for multiple bindings on one resource. It seems that we're still far from consensus, so I'd like to submit this draft (undoing the broken REBIND description) ASAP. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 9 15:29:42 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01152 for ; Thu, 9 Dec 2004 15:29:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcUuC-0000oO-AI for w3c-dist-auth-dist@listhub.w3.org; Thu, 09 Dec 2004 20:28:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CcUu9-0000nm-GZ for w3c-dist-auth@listhub.w3.org; Thu, 09 Dec 2004 20:28:49 +0000 Received: from smtpout.mac.com ([17.250.248.86]) by lisa.w3.org with esmtp (Exim 4.34) id 1CcUu1-0000h5-Sl for w3c-dist-auth@w3.org; Thu, 09 Dec 2004 20:28:42 +0000 Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id iB9KSl9i018720 for ; Thu, 9 Dec 2004 12:28:47 -0800 (PST) Received: from [168.16.213.98] (sleepy.gcsu.edu [168.16.213.98]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id iB9KShZg004519 for ; Thu, 9 Dec 2004 12:28:45 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <167E48B5-4978-11D9-AC43-000A95B2BB72@osafoundation.org> References: <200412090000.iB900C74000213@cats-mx1.ucsc.edu> <167E48B5-4978-11D9-AC43-000A95B2BB72@osafoundation.org> Date: Thu, 9 Dec 2004 15:28:40 -0500 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received-SPF: none (lisa.w3.org: domain of frank.lowney@mac.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: WebDAV, URL encoding and current Windows clients X-Archived-At: http://www.w3.org/mid/p0620070cbdde5c747729@%5B168.16.213.98%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9167 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 09 Dec 2004 20:28:52 +0000 Content-Transfer-Encoding: quoted-printable WebDAV, URL encoding and current Windows clients
I am caught in the middle of a "he said - she said" kind of discussion about what constitutes a valid URI/URL for WebDAV and am posting here in the hope of getting an authoritative answer as to which statement is truer: use "+" or use "%20"  Here's the story:

There is a Learning Management System called WebCT Vista.  It uses an Oracle DB back end and a java-based webserver called "WebLogic" from a company called BEA.  The problem at hand is confined to Windows clients.  Mac clients seems to work as well with this system as they do with Apache and WebSTAR V,  The way WebCT Vista enables the use of WebDAV is that it generates a URI that the client copies and pastes into a WebDAV client application.  Here's an example:

http://vista.gsu.edu:8000/webct/webdav/131.96.160.58-1044482159055-3283261001.flowney/University+System+of+Georgia/Georgia+College+and+State+University/Documentation/Vista+3.0+Documentation/Vista+3.0+Dox.01/Section+Content

WebCT Vista puts a "+" char in place of those spaces but this causes Windows clients to gag and report that "The folder you are trying to access is invalid" or words to that effect.  Microsoft has published work around strategies for this (see below the dotted line). This problem manifests itself only where there are spaces in the path and only with the more recent Microsoft clients.  Older clients don't seem to be bothered by this.

The engineers at WebCT Inc say that the "+" is kosher citing authorities such as:

If you look at this page:
http://www.w3.org/International/O-URL-code.html

It provides some java classes that does URI encoding.
When you get the program running and entered a space, you will get a + in return.

If you take a look at the source code, you can find this comment:

"The space character ' ' is converted into a plus sign '+'."

Others suggest that spaces should be encoded as %20 in order to be valid.

Is this a peculiarity of Java code, an Oracke requirement or just idiosyncratic for WebCT Inc.  More importantly, which encoding strategy is more valid, more robust?

Has Microsoft gone and broken WebDAV on Windows?



------------------ Microsoft on WebDAV Issues ----------------------------
Some more information for anyone troubleshooting Windows WebDAV connections
http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;269681
Error:

You attempt to add a Web folder to the My Network Places folder, but you are unsuccessful and you receive the following error message:

=A1=A7The folder you entered does not appear to be valid =A1=A7
Cause:

This behavior may occur if you have a system policy that redirects the user's Application Data folder and prevents the creation of the Msdaipp folder that the Web Folders feature uses. The Msdaipp folder is normally located under the user's Userprofile\Application Data\Microsoft folder.

When you do not use this system policy, the first time you create a Web folder in the My Network Places folder with the Add Network Place Wizard, a subdirectory is created. If you set a system policy to change the Userprofile\Application Data folder to a universal naming convention (UNC) on a network server, this wizard does not create the Msdaipp folder at the redirected location and you receive the preceding error message.

=46ix as suggested by a Microsoft Online Partner Support rep:

1. Open the UNC path specified Target Location Folder.
2. Ensure that you can view hidden files, and then open the Microsoft directory.
3. Create a folder called Msdaipp.
4. Check with this issue again.
 
However, if the issue persists, please perform the following steps to create a new account with the Computer Administrator privilege and see how things are going on.
 
1) Click Start, and click Control Panel.
2) Double-click "User Accounts".
3) Click the "Create a new account" link.
4) Follow the instruction to create a new account with the Computer Administrator privilege.
5) Log off the current user account and then log on the new account.
 
Also, please perform the troubleshooting steps in the following article: 287402 =A1=A7Troubleshooting Web Folders=A1=A8
http://support.microsoft.com/?id=3D287402


 
B) Sometimes the Web =46older client in Windows could have been changed by another piece of software (for example, Microsoft Office).  Please consider following the instructions to restore the WebDAV client to the original one.
 
1.  Find a file called webfldrs.msi (Normally under WINDOWS\SYSTEM32\webfldrs.msi - if you installed Windows XP Servicepack 1 you will find it under WINDOWS\ServicePackFiles\i386webfldrs.msi).  E.g. C:\WINNT\system32
2.  Start the installation with double-click or right-click -> webfldrs.msi.
3.  Now you have to click on "Select reinstall mode".
=B7    Uncheck "Repair all detected reinstall problems".
=B7    Check "Force all files to be reinstalled, regardless of checksum or version".
=B7    Check "Verify that required user registry entries are present".
=B7    Check "Verify that required machine registry entries are present".
=B7    Check "Validate shortcuts".
4.  Press OK and REINSTALL
5.  Normally no reboot is required. Now the web folder client should have been restored as it was shipped.
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr. Frank Lowney  frank.lowney@gcsu.edu
    Director, Electronic Instructional Services, a unit of the
    Office of Information and Instructional Technology,
    Professional Pages: http://www.gcsu.edu/oiit/eis/
    Personal Pages: http://www.faculty.de.gcsu.edu/~flowney
Voice: (478) 445-5260
NOTICE: Please be advised that I am hearing impaired and communicate most effectively via e-mail.  Follow-up summaries of telephone conversations by e-mail are most appreciated.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We don't make instruction effective, we make effective instruction more accessible.
From w3c-dist-auth-request@w3.org Thu Dec 9 15:49:27 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02814 for ; Thu, 9 Dec 2004 15:49:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcVDQ-0006fe-Tb for w3c-dist-auth-dist@listhub.w3.org; Thu, 09 Dec 2004 20:48:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CcVDL-0006dg-IK for w3c-dist-auth@listhub.w3.org; Thu, 09 Dec 2004 20:48:39 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CcVDE-0006gj-0U for w3c-dist-auth@w3.org; Thu, 09 Dec 2004 20:48:32 +0000 Received: (qmail invoked by alias); 09 Dec 2004 20:48:07 -0000 Received: from p54856FE9.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.111.233) by mail.gmx.net (mp024) with SMTP; 09 Dec 2004 21:48:07 +0100 X-Authenticated: #1915285 Message-ID: <41B8B9F8.4020503@gmx.de> Date: Thu, 09 Dec 2004 21:47:52 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank Lowney CC: w3c-dist-auth@w3.org References: <200412090000.iB900C74000213@cats-mx1.ucsc.edu> <167E48B5-4978-11D9-AC43-000A95B2BB72@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV, URL encoding and current Windows clients X-Archived-At: http://www.w3.org/mid/41B8B9F8.4020503@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9168 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 09 Dec 2004 20:48:44 +0000 Content-Transfer-Encoding: 7bit Frank Lowney wrote: > I am caught in the middle of a "he said - she said" kind of discussion > about what constitutes a valid URI/URL for WebDAV and am posting here in > the hope of getting an authoritative answer as to which statement is > truer: use "+" or use "%20" Here's the story: > > There is a Learning Management System called WebCT Vista. It uses an > Oracle DB back end and a java-based webserver called "WebLogic" from a > company called BEA. The problem at hand is confined to Windows > clients. Mac clients seems to work as well with this system as they do > with Apache and WebSTAR V, The way WebCT Vista enables the use of > WebDAV is that it generates a URI that the client copies and pastes into > a WebDAV client application. Here's an example: > > http://vista.gsu.edu:8000/webct/webdav/131.96.160.58-1044482159055-3283261001.flowney/University+System+of+Georgia/Georgia+College+and+State+University/Documentation/Vista+3.0+Documentation/Vista+3.0+Dox.01/Section+Content > > WebCT Vista puts a "+" char in place of those spaces but this causes > Windows clients to gag and report that "The folder you are trying to > access is invalid" or words to that effect. Microsoft has published > work around strategies for this (see below the dotted line). This > problem manifests itself only where there are spaces in the path and > only with the more recent Microsoft clients. Older clients don't seem > to be bothered by this. > > The engineers at WebCT Inc say that the "+" is kosher citing authorities > such as: > > If you look at this page: > > http://www.w3.org/International/O-URL-code.html > > > It provides some java classes that does URI encoding. > > When you get the program running and entered a space, you will get a > + in return. > > > If you take a look at the source code, you can find this comment: > > > "The space character ' ' is converted into a plus sign '+'." > > > Others suggest that spaces should be encoded as %20 in order to be valid. > > Is this a peculiarity of Java code, an Oracke requirement or just > idiosyncratic for WebCT Inc. More importantly, which encoding strategy > is more valid, more robust? > > Has Microsoft gone and broken WebDAV on Windows? Yes, but in this case it may not be the root of the problem. It is true that blank spaces must be escaped, but this is usually done using "%20". As far I can tell, "+" only has a special meaning within the query part. Details in RFC2396 (); the W3C is not normative here; in particular not random source code samples... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 9 15:50:53 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02919 for ; Thu, 9 Dec 2004 15:50:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcVEw-0007g7-DY for w3c-dist-auth-dist@listhub.w3.org; Thu, 09 Dec 2004 20:50:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CcVEv-0007em-PL for w3c-dist-auth@listhub.w3.org; Thu, 09 Dec 2004 20:50:17 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by lisa.w3.org with esmtp (Exim 4.34) id 1CcVEo-0007Go-21 for w3c-dist-auth@w3.org; Thu, 09 Dec 2004 20:50:10 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iB9KmiX8000016; Thu, 9 Dec 2004 12:48:47 -0800 (PST) Message-Id: <200412092048.iB9KmiX8000016@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Frank Lowney'" , Date: Thu, 9 Dec 2004 12:48:37 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01C4DDED.6BCF4570" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTeLb5AatgGbRbIQ9+EWZ+JzV7CRwAAb95g X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: WebDAV, URL encoding and current Windows clients X-Archived-At: http://www.w3.org/mid/200412092048.iB9KmiX8000016@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9169 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 09 Dec 2004 20:50:18 +0000 This is a multi-part message in MIME format. ------=_NextPart_000_008F_01C4DDED.6BCF4570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The authoritative reference here is RFC 2396 http://www.ietf.org/rfc/rfc2396.txt =20 According to the BNF productions in Appendix A, the plus character is perfectly legal within a URI, including HTTP scheme. RFC 2616 explicitly references RFC 2396. =20 The relevant productions are: =20 URI-reference =3D [ absoluteURI | relativeURI ] [ "#" fragment ] =20 absoluteURI =3D scheme ":" ( hier_part | opaque_part ) =20 hier_part =3D ( net_path | abs_path ) [ "?" query ] =20 net_path =3D "//" authority [ abs_path ] abs_path =3D "/" path_segments =20 =20 path_segments =3D segment *( "/" segment ) segment =3D *pchar *( ";" param ) param =3D *pchar pchar =3D unreserved | escaped | ":" | "@" | "&" | "=3D" | "+" | "$" | "," =20 =20 Hope this helps. =20 - Jim _____ =20 From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On Behalf Of Frank Lowney Sent: Thursday, December 09, 2004 12:29 PM To: w3c-dist-auth@w3.org Subject: WebDAV, URL encoding and current Windows clients I am caught in the middle of a "he said - she said" kind of discussion = about what constitutes a valid URI/URL for WebDAV and am posting here in the = hope of getting an authoritative answer as to which statement is truer: use = "+" or use "%20" Here's the story: There is a Learning Management System called WebCT Vista. It uses an = Oracle DB back end and a java-based webserver called "WebLogic" from a company called BEA. The problem at hand is confined to Windows clients. Mac clients seems to work as well with this system as they do with Apache = and WebSTAR V, The way WebCT Vista enables the use of WebDAV is that it generates a URI that the client copies and pastes into a WebDAV client application. Here's an example: http://vista.gsu.edu:8000/webct/webdav/131.96.160.58-1044482159055-328326= 100 1.flowney/University+System+of+Georgia/Georgia+College+and+State+Universi= ty/ Documentation/Vista+3.0+Documentation/Vista+3.0+Dox.01/Section+Content WebCT Vista puts a "+" char in place of those spaces but this causes = Windows clients to gag and report that "The folder you are trying to access is invalid" or words to that effect. Microsoft has published work around strategies for this (see below the dotted line). This problem manifests itself only where there are spaces in the path and only with the more = recent Microsoft clients. Older clients don't seem to be bothered by this. The engineers at WebCT Inc say that the "+" is kosher citing authorities such as: If you look at this page: http://www.w3.org/International/O-URL-code.html It provides some java classes that does URI encoding. When you get the program running and entered a space, you will get a + = in return. If you take a look at the source code, you can find this comment: "The space character ' ' is converted into a plus sign '+'." Others suggest that spaces should be encoded as %20 in order to be = valid. Is this a peculiarity of Java code, an Oracke requirement or just idiosyncratic for WebCT Inc. More importantly, which encoding strategy = is more valid, more robust? Has Microsoft gone and broken WebDAV on Windows?=20 ------------------ Microsoft on WebDAV Issues = ---------------------------- Some more information for anyone troubleshooting Windows WebDAV = connections http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;269681 Error: You attempt to add a Web folder to the My Network Places folder, but you = are unsuccessful and you receive the following error message: =A1=A7The folder you entered does not appear to be valid =A1=A7 Cause: This behavior may occur if you have a system policy that redirects the user's Application Data folder and prevents the creation of the Msdaipp folder that the Web Folders feature uses. The Msdaipp folder is normally located under the user's Userprofile\Application Data\Microsoft folder. When you do not use this system policy, the first time you create a Web folder in the My Network Places folder with the Add Network Place = Wizard, a subdirectory is created. If you set a system policy to change the Userprofile\Application Data folder to a universal naming convention = (UNC) on a network server, this wizard does not create the Msdaipp folder at = the redirected location and you receive the preceding error message. Fix as suggested by a Microsoft Online Partner Support rep: 1. Open the UNC path specified Target Location Folder. 2. Ensure that you can view hidden files, and then open the Microsoft directory. 3. Create a folder called Msdaipp. 4. Check with this issue again. =20 However, if the issue persists, please perform the following steps to = create a new account with the Computer Administrator privilege and see how = things are going on. =20 1) Click Start, and click Control Panel. 2) Double-click "User Accounts". 3) Click the "Create a new account" link. 4) Follow the instruction to create a new account with the Computer Administrator privilege. 5) Log off the current user account and then log on the new account. =20 Also, please perform the troubleshooting steps in the following article: 287402 =A1=A7Troubleshooting Web Folders=A1=A8 http://support.microsoft.com/?id=3D287402 A) Replace the + signs with spaces. e.g. http://test.webct.com/webct/webdav/10.1.6.95-1084809904923-2001072000.200= 107 3000/Domain Name/Test Instituite =20 B) Sometimes the Web Folder client in Windows could have been changed by another piece of software (for example, Microsoft Office). Please = consider following the instructions to restore the WebDAV client to the original = one. =20 1. Find a file called webfldrs.msi (Normally under WINDOWS\SYSTEM32\webfldrs.msi - if you installed Windows XP Servicepack = 1 you will find it under WINDOWS\ServicePackFiles\i386webfldrs.msi). E.g. C:\WINNT\system32 2. Start the installation with double-click or right-click -> = webfldrs.msi. 3. Now you have to click on "Select reinstall mode". =B7 Uncheck "Repair all detected reinstall problems". =B7 Check "Force all files to be reinstalled, regardless of checksum = or version". =B7 Check "Verify that required user registry entries are present". =B7 Check "Verify that required machine registry entries are = present". =B7 Check "Validate shortcuts". 4. Press OK and REINSTALL 5. Normally no reboot is required. Now the web folder client should = have been restored as it was shipped. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Frank Lowney frank.lowney@gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 NOTICE: Please be advised that I am hearing impaired and communicate = most effectively via e-mail. Follow-up summaries of telephone conversations = by e-mail are most appreciated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We don't make instruction effective, we make effective instruction more accessible. ------=_NextPart_000_008F_01C4DDED.6BCF4570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WebDAV, URL encoding and current Windows = clients
The authoritative reference here is RFC 2396 http://www.ietf.org/rfc/rfc2= 396.txt
 
According to the BNF productions in Appendix A, = the plus=20 character is perfectly legal within a URI, including HTTP scheme. RFC = 2616=20 explicitly references RFC 2396.
 
The relevant productions = are:
 
URI-reference =
=3D [ absoluteURI | relativeURI ] [ "#" fragment ]
 
absoluteURI   =3D scheme ":" ( hier_part | opaque_part =
)
 
hier_part     =3D ( net_path | =
abs_path ) [ "?" query ]
 
net_path   =
   =3D "//" authority [ abs_path ]
abs_path      =3D "/"  =
path_segments
 
 =

path_segments =3D segment *( "/" segment )
segment       =3D *pchar *( ";" param )
param         =3D *pchar
pchar         =3D unreserved | escaped |
                 ":" | "@" | "&" | "=3D" | "+" | "$" | =
","
 
 
Hope this =
helps.
 
- =
Jim

From: w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Frank=20 Lowney
Sent: Thursday, December 09, 2004 12:29 = PM
To:=20 w3c-dist-auth@w3.org
Subject: WebDAV, URL encoding and = current=20 Windows clients

I am caught in the middle of a "he said - she said" kind of = discussion=20 about what constitutes a valid URI/URL for WebDAV and am posting here = in the=20 hope of getting an authoritative answer as to which statement is = truer: use=20 "+" or use "%20"  Here's the story:

There is a Learning Management System called WebCT Vista.  = It uses=20 an Oracle DB back end and a java-based webserver called "WebLogic" = from a=20 company called BEA.  The problem at hand is confined to Windows=20 clients.  Mac clients seems to work as well with this system as = they do=20 with Apache and WebSTAR V,  The way WebCT Vista enables the use = of WebDAV=20 is that it generates a URI that the client copies and pastes into a = WebDAV=20 client application.  Here's an example:

=
http://vista.gsu.edu:8000/webct/webdav/131.96.160.58-1044482159055-3= 283261001.flowney/University+System+of+Georgia/Georgia+Colle= ge+and+State+University/Documentation/Vista+3.0+Documentatio= n/Vista+3.0+Dox.01/Section+Content

WebCT Vista puts a "+" char in place of those spaces but this = causes=20 Windows clients to gag and report that "The folder you are trying to = access is=20 invalid" or words to that effect.  Microsoft has published work = around=20 strategies for this (see below the dotted line). This problem = manifests itself=20 only where there are spaces in the path and only with the more recent=20 Microsoft clients.  Older clients don't seem to be bothered by=20 this.

The engineers at WebCT Inc say that the "+" is kosher citing = authorities=20 such as:

If you look at this page:
=
http://www.w3.org/International/O-URL-code.html

It provides some java classes that does URI = encoding.
When you get the program running and entered a space, you = will=20 get a + in return.

If you take a look at the source code, you can find this=20 comment:

"The space character ' ' is converted into a plus sign=20 '+'."

Others suggest that spaces should be encoded as %20 in order to = be=20 valid.

Is this a peculiarity of Java code, an Oracke requirement or just = idiosyncratic for WebCT Inc.  More importantly, which encoding = strategy=20 is more valid, more robust?

Has Microsoft gone and broken WebDAV on Windows?



------------------ Microsoft on WebDAV Issues=20 ----------------------------
Some more information for anyone troubleshooting Windows WebDAV=20 = connections
http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;= 269681
Error:

You=20 attempt to add a Web folder to the My Network Places folder, but you = are=20 unsuccessful and you receive the following error = message:

=A1=A7The folder=20 you entered does not appear to be valid =A1=A7
Cause:

This = behavior may=20 occur if you have a system policy that redirects the user's = Application Data=20 folder and prevents the creation of the Msdaipp folder that the Web = Folders=20 feature uses. The Msdaipp folder is normally located under the user's=20 Userprofile\Application Data\Microsoft folder.

When you do not = use this=20 system policy, the first time you create a Web folder in the My = Network Places=20 folder with the Add Network Place Wizard, a subdirectory is created. = If you=20 set a system policy to change the Userprofile\Application Data folder = to a=20 universal naming convention (UNC) on a network server, this wizard = does not=20 create the Msdaipp folder at the redirected location and you receive = the=20 preceding error message.

Fix as suggested by a Microsoft Online = Partner=20 Support rep:

1. Open the UNC path specified Target Location=20 Folder.
2. Ensure that you can view hidden files, and then open the = Microsoft directory.
3. Create a folder called Msdaipp.
4. Check = with=20 this issue again.
 
However, if the issue persists, please = perform=20 the following steps to create a new account with the Computer = Administrator=20 privilege and see how things are going on.
 
1) Click = Start, and=20 click Control Panel.
2) Double-click "User Accounts".
3) Click = the=20 "Create a new account" link.
4) Follow the instruction to create a = new=20 account with the Computer Administrator privilege.
5) Log off the = current=20 user account and then log on the new account.
 
Also, please perform the troubleshooting steps in the following = article:=20 287402 =A1=A7Troubleshooting Web Folders=A1=A8
http://support.microsoft.com/?id=3D287402


A)  Replace = the + signs=20 with spaces.
e.g. http://test.webct.com/webct/webdav/1= 0.1.6.95-1084809904923-2001072000.2001073000/Domain Name/Test = Instituite
 
B) Sometimes the = Web Folder=20 client in Windows could have been changed by another piece of software = (for=20 example, Microsoft Office).  Please consider following the = instructions=20 to restore the WebDAV client to the original one.
 
1.  Find a = file called=20 webfldrs.msi (Normally under WINDOWS\SYSTEM32\webfldrs.msi - if you = installed=20 Windows XP Servicepack 1 you will find it under=20 WINDOWS\ServicePackFiles\i386webfldrs.msi).  E.g.=20 C:\WINNT\system32
2.  Start the installation with double-click = or=20 right-click -> webfldrs.msi.
3.  Now you have to click on = "Select=20 reinstall mode".
=B7    Uncheck "Repair all detected = reinstall=20 problems".
=B7    Check "Force all files to be = reinstalled,=20 regardless of checksum or version".
=B7    Check = "Verify that=20 required user registry entries are present".
=B7    = Check=20 "Verify that required machine registry entries are=20 present".
=B7    Check "Validate = shortcuts".
4.  Press=20 OK and REINSTALL
5.  Normally = no reboot is=20 required. Now the web folder client should have been restored as it = was=20 shipped.
--=20
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr.=20 Frank Lowney  frank.lowney@gcsu.edu
    = Director,=20 Electronic Instructional Services, a unit of the
    = Office=20 of Information and Instructional Technology,
   =20 Professional Pages: = http://www.gcsu.edu/oiit/eis/
   =20 Personal Pages: http://www.faculty.de.gcsu.edu/~flowney
Voice: = (478)=20 445-5260
NOTICE: Please be advised that I am hearing impaired and=20 communicate most effectively via e-mail.  Follow-up summaries of=20 telephone conversations by e-mail are most=20 = appreciated.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
We=20 don't make instruction effective, we make effective instruction more=20 accessible.
------=_NextPart_000_008F_01C4DDED.6BCF4570-- From w3c-dist-auth-request@w3.org Thu Dec 9 15:52:15 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03025 for ; Thu, 9 Dec 2004 15:52:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcVGI-00087M-LI for w3c-dist-auth-dist@listhub.w3.org; Thu, 09 Dec 2004 20:51:42 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CcVGH-00086o-O6 for w3c-dist-auth@listhub.w3.org; Thu, 09 Dec 2004 20:51:41 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1CcVGG-0005Rv-VH for w3c-dist-auth@w3.org; Thu, 09 Dec 2004 20:51:41 +0000 Received: from [192.168.0.3] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.1.R) with ESMTP id md50000067176.msg for ; Thu, 09 Dec 2004 21:50:44 +0100 In-Reply-To: References: <200412090000.iB900C74000213@cats-mx1.ucsc.edu> <167E48B5-4978-11D9-AC43-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: w3c-dist-auth@w3.org From: Stefan Eissing Date: Thu, 9 Dec 2004 21:50:39 +0100 To: Frank Lowney X-Mailer: Apple Mail (2.619) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Thu, 09 Dec 2004 21:50:44 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Received-SPF: none (bart.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV, URL encoding and current Windows clients X-Archived-At: http://www.w3.org/mid/FC152F1A-4A23-11D9-B837-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9170 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 09 Dec 2004 20:51:42 +0000 Content-Transfer-Encoding: quoted-printable Frank, if you look at the URI RFC (old and new) you'll see that spaces in the =20= path components are encoded with %20 and that '+' has no special =20 meaning there. The encoding with '+' is only used in query parameters =20= to the URL. This however is not the case in your example. The URI in =20 your example should be endoded using %20. Regards, Stefan Am 09.12.2004 um 21:28 schrieb Frank Lowney: > I am caught in the middle of a "he said - she said" kind of discussion = =20 > about what constitutes a valid URI/URL for WebDAV and am posting here =20= > in the hope of getting an authoritative answer as to which statement =20= > is truer: use "+" or use "%20"=A0 Here's the story: > > There is a Learning Management System called WebCT Vista.=A0 It uses = an =20 > Oracle DB back end and a java-based webserver called "WebLogic" from a = =20 > company called BEA.=A0 The problem at hand is confined to Windows =20 > clients.=A0 Mac clients seems to work as well with this system as they = =20 > do with Apache and WebSTAR V,=A0 The way WebCT Vista enables the use = of =20 > WebDAV is that it generates a URI that the client copies and pastes =20= > into a WebDAV client application.=A0 Here's an example: > > http://vista.gsu.edu:8000/webct/webdav/131.96.160.58-1044482159055=20 > -3283261001.flowney/University+System+of+Georgia/=20 > Georgia+College+and+State+University/Documentation/=20 > Vista+3.0+Documentation/Vista+3.0+Dox.01/Section+Content > > WebCT Vista puts a "+" char in place of those spaces but this causes =20= > Windows clients to gag and report that "The folder you are trying to =20= > access is invalid" or words to that effect.=A0 Microsoft has published = =20 > work around strategies for this (see below the dotted line). This =20 > problem manifests itself only where there are spaces in the path and =20= > only with the more recent Microsoft clients.=A0 Older clients don't = seem =20 > to be bothered by this. > > The engineers at WebCT Inc say that the "+" is kosher citing =20 > authorities such as: > > If you look at this page: > http://www.w3.org/International/O-URL-code.html > > It provides some java classes that does URI encoding. > When you get the program running and entered a space, you will get a + = =20 > in return. > > If you take a look at the source code, you can find this comment: > > "The space character ' ' is converted into a plus sign '+'." > > Others suggest that spaces should be encoded as %20 in order to be =20 > valid. > > Is this a peculiarity of Java code, an Oracke requirement or just =20 > idiosyncratic for WebCT Inc.=A0 More importantly, which encoding =20 > strategy is more valid, more robust? > > Has Microsoft gone and broken WebDAV on Windows? > > > > ------------------ Microsoft on WebDAV Issues =20 > ---------------------------- > Some more information for anyone troubleshooting Windows WebDAV =20 > connections > http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;269681 > Error: > > You attempt to add a Web folder to the My Network Places folder, but =20= > you are unsuccessful and you receive the following error message: > > =A1=A7The folder you entered does not appear to be valid =A1=A7 > Cause: > > This behavior may occur if you have a system policy that redirects =20= > the user's Application Data folder and prevents the creation of the =20= > Msdaipp folder that the Web Folders feature uses. The Msdaipp folder =20= > is normally located under the user's Userprofile\Application =20 > Data\Microsoft folder. > > When you do not use this system policy, the first time you create a =20= > Web folder in the My Network Places folder with the Add Network Place =20= > Wizard, a subdirectory is created. If you set a system policy to =20 > change the Userprofile\Application Data folder to a universal naming =20= > convention (UNC) on a network server, this wizard does not create the =20= > Msdaipp folder at the redirected location and you receive the =20 > preceding error message. > > Fix as suggested by a Microsoft Online Partner Support rep: > > 1. Open the UNC path specified Target Location Folder. > 2. Ensure that you can view hidden files, and then open the Microsoft = =20 > directory. > 3. Create a folder called Msdaipp. > 4. Check with this issue again. > =A0 > However, if the issue persists, please perform the following steps to = =20 > create a new account with the Computer Administrator privilege and see = =20 > how things are going on. > =A0 > 1) Click Start, and click Control Panel. > 2) Double-click "User Accounts". > 3) Click the "Create a new account" link. > 4) Follow the instruction to create a new account with the Computer =20= > Administrator privilege. > 5) Log off the current user account and then log on the new account. > =A0 > Also, please perform the troubleshooting steps in the following =20 > article: 287402 =A1=A7Troubleshooting Web Folders=A1=A8 > http://support.microsoft.com/?id=3D287402 > > > A)=A0 Replace the + signs with spaces. > e.g. =20 > http://test.webct.com/webct/webdav/10.1.6.95-1084809904923=20 > -2001072000.2001073000/Domain Name/Test Instituite > =A0 > B) Sometimes the Web Folder client in Windows could have been changed =20= > by another piece of software (for example, Microsoft Office).=A0 = Please =20 > consider following the instructions to restore the WebDAV client to =20= > the original one. > =A0 > 1.=A0 Find a file called webfldrs.msi (Normally under =20 > WINDOWS\SYSTEM32\webfldrs.msi - if you installed Windows XP =20 > Servicepack 1 you will find it under =20 > WINDOWS\ServicePackFiles\i386webfldrs.msi).=A0 E.g. C:\WINNT\system32 > 2.=A0 Start the installation with double-click or right-click -> =20 > webfldrs.msi. > 3.=A0 Now you have to click on "Select reinstall mode". > =B7=A0=A0=A0 Uncheck "Repair all detected reinstall problems". > =B7=A0=A0=A0 Check "Force all files to be reinstalled, regardless of = checksum =20 > or version". > =B7=A0=A0=A0 Check "Verify that required user registry entries are = present". > =B7=A0=A0=A0 Check "Verify that required machine registry entries are = =20 > present". > =B7=A0=A0=A0 Check "Validate shortcuts". > 4.=A0 Press OK and REINSTALL > 5.=A0 Normally no reboot is required. Now the web folder client should = =20 > have been restored as it was shipped. > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dr. Frank Lowney=A0 frank.lowney@gcsu.edu > =A0=A0=A0 Director, Electronic Instructional Services, a unit of the > =A0=A0=A0 Office of Information and Instructional Technology, > =A0=A0=A0 Professional Pages: http://www.gcsu.edu/oiit/eis/ > =A0=A0=A0 Personal Pages: http://www.faculty.de.gcsu.edu/~flowney > Voice: (478) 445-5260 > NOTICE: Please be advised that I am hearing impaired and communicate =20= > most effectively via e-mail.=A0 Follow-up summaries of telephone =20 > conversations by e-mail are most appreciated. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > We don't make instruction effective, we make effective instruction =20= > more accessible. > From w3c-dist-auth-request@w3.org Thu Dec 9 16:05:45 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04098 for ; Thu, 9 Dec 2004 16:05:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcVSS-0002bL-4D for w3c-dist-auth-dist@listhub.w3.org; Thu, 09 Dec 2004 21:04:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CcVSR-0002ar-K4 for w3c-dist-auth@listhub.w3.org; Thu, 09 Dec 2004 21:04:15 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.34) id 1CcVSK-0002ep-0n for w3c-dist-auth@w3.org; Thu, 09 Dec 2004 21:04:08 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id iB9LBXbk025598 for ; Thu, 9 Dec 2004 13:11:33 -0800 (PST) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Thu, 9 Dec 2004 13:04:53 -0800 Received: from [17.202.43.76] (luthji.apple.com [17.202.43.76]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id iB9L3QOa021917; Thu, 9 Dec 2004 13:03:26 -0800 (PST) In-Reply-To: References: <200412090000.iB900C74000213@cats-mx1.ucsc.edu> <167E48B5-4978-11D9-AC43-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v682) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1FBE6521-E9CD-4D71-A221-A632692A3DB5@apple.com> Cc: Frank Lowney Content-Transfer-Encoding: quoted-printable From: Jim Luther Date: Thu, 9 Dec 2004 13:03:24 -0800 To: w3c-dist-auth@w3.org X-Mailer: Apple Mail (2.682) Received-SPF: pass (lisa.w3.org: domain of luther.j@apple.com designates 17.254.13.23 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV, URL encoding and current Windows clients X-Archived-At: http://www.w3.org/mid/1FBE6521-E9CD-4D71-A221-A632692A3DB5@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9171 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 09 Dec 2004 21:04:16 +0000 Content-Transfer-Encoding: quoted-printable The problem with the "+" character may be a FAT naming convention =20 problem (for the FAT documentation, go to =20 ). =20= It says this about FAT short names: > The following characters are not legal in any bytes of DIR_Name: > * Values less than 0x20 except for the special case of 0x05 in =20 > DIR_Name[0] described above. > * 0x22, 0x2A, 0x2B, 0x2C, 0x2E, 0x2F, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, =20= > 0x3F, 0x5B, 0x5C, 0x5D, and 0x7C. That includes the "+" character (0x2B). It also says this about FAT =20 long names: > The following six special characters are now allowed in a long name. =20= > They are not legal in a short name. > > + , ; =3D [ ] So it could be something enforcing FAT short name character limitations. Just a guess... - Jim On Dec 9, 2004, at 12:28 PM, Frank Lowney wrote: > I am caught in the middle of a "he said - she said" kind of discussion = =20 > about what constitutes a valid URI/URL for WebDAV and am posting here =20= > in the hope of getting an authoritative answer as to which statement =20= > is truer: use "+" or use "%20"=A0 Here's the story: > > There is a Learning Management System called WebCT Vista.=A0 It uses = an =20 > Oracle DB back end and a java-based webserver called "WebLogic" from a = =20 > company called BEA.=A0 The problem at hand is confined to Windows =20 > clients.=A0 Mac clients seems to work as well with this system as they = =20 > do with Apache and WebSTAR V,=A0 The way WebCT Vista enables the use = of =20 > WebDAV is that it generates a URI that the client copies and pastes =20= > into a WebDAV client application.=A0 Here's an example: > > http://vista.gsu.edu:8000/webct/webdav/=20 > 131.96.160.58-1044482159055-3283261001.flowney/University+System+of=20 > +Georgia/Georgia+College+and+State+University/Documentation/Vista+3.0=20= > +Documentation/Vista+3.0+Dox.01/Section+Content > > WebCT Vista puts a "+" char in place of those spaces but this causes =20= > Windows clients to gag and report that "The folder you are trying to =20= > access is invalid" or words to that effect.=A0 Microsoft has published = =20 > work around strategies for this (see below the dotted line). This =20 > problem manifests itself only where there are spaces in the path and =20= > only with the more recent Microsoft clients.=A0 Older clients don't = seem =20 > to be bothered by this. > > The engineers at WebCT Inc say that the "+" is kosher citing =20 > authorities such as: > > If you look at this page: > http://www.w3.org/International/O-URL-code.html > > It provides some java classes that does URI encoding. > When you get the program running and entered a space, you will get a + = =20 > in return. > > If you take a look at the source code, you can find this comment: > > "The space character ' ' is converted into a plus sign '+'." > > Others suggest that spaces should be encoded as %20 in order to be =20 > valid. > > Is this a peculiarity of Java code, an Oracke requirement or just =20 > idiosyncratic for WebCT Inc.=A0 More importantly, which encoding =20 > strategy is more valid, more robust? > > Has Microsoft gone and broken WebDAV on Windows? > > > > ------------------ Microsoft on WebDAV Issues =20 > ---------------------------- > Some more information for anyone troubleshooting Windows WebDAV =20 > connections > http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;269681 > Error: > > You attempt to add a Web folder to the My Network Places folder, but =20= > you are unsuccessful and you receive the following error message: > > =A1=A7The folder you entered does not appear to be valid =A1=A7 > Cause: > > This behavior may occur if you have a system policy that redirects the = =20 > user's Application Data folder and prevents the creation of the =20 > Msdaipp folder that the Web Folders feature uses. The Msdaipp folder =20= > is normally located under the user's Userprofile\Application =20 > Data\Microsoft folder. > > When you do not use this system policy, the first time you create a =20= > Web folder in the My Network Places folder with the Add Network Place =20= > Wizard, a subdirectory is created. If you set a system policy to =20 > change the Userprofile\Application Data folder to a universal naming =20= > convention (UNC) on a network server, this wizard does not create the =20= > Msdaipp folder at the redirected location and you receive the =20 > preceding error message. > > Fix as suggested by a Microsoft Online Partner Support rep: > > 1. Open the UNC path specified Target Location Folder. > 2. Ensure that you can view hidden files, and then open the Microsoft =20= > directory. > 3. Create a folder called Msdaipp. > 4. Check with this issue again. > =A0 > However, if the issue persists, please perform the following steps to =20= > create a new account with the Computer Administrator privilege and see = =20 > how things are going on. > =A0 > 1) Click Start, and click Control Panel. > 2) Double-click "User Accounts". > 3) Click the "Create a new account" link. > 4) Follow the instruction to create a new account with the Computer =20= > Administrator privilege. > 5) Log off the current user account and then log on the new account. > =A0 > Also, please perform the troubleshooting steps in the following =20 > article: 287402 =A1=A7Troubleshooting Web Folders=A1=A8 > http://support.microsoft.com/?id=3D287402 > > > A)=A0 Replace the + signs with spaces. > e.g. =20 > http://test.webct.com/webct/webdav/=20 > 10.1.6.95-1084809904923-2001072000.2001073000/Domain Name/Test =20 > Instituite > =A0 > B) Sometimes the Web Folder client in Windows could have been changed =20= > by another piece of software (for example, Microsoft Office).=A0 = Please =20 > consider following the instructions to restore the WebDAV client to =20= > the original one. > =A0 > 1.=A0 Find a file called webfldrs.msi (Normally under =20 > WINDOWS\SYSTEM32\webfldrs.msi - if you installed Windows XP =20 > Servicepack 1 you will find it under =20 > WINDOWS\ServicePackFiles\i386webfldrs.msi).=A0 E.g. C:\WINNT\system32 > 2.=A0 Start the installation with double-click or right-click -> =20 > webfldrs.msi. > 3.=A0 Now you have to click on "Select reinstall mode". > =B7=A0=A0=A0 Uncheck "Repair all detected reinstall problems". > =B7=A0=A0=A0 Check "Force all files to be reinstalled, regardless of = checksum =20 > or version". > =B7=A0=A0=A0 Check "Verify that required user registry entries are = present". > =B7=A0=A0=A0 Check "Verify that required machine registry entries are = present". > =B7=A0=A0=A0 Check "Validate shortcuts". > 4.=A0 Press OK and REINSTALL > 5.=A0 Normally no reboot is required. Now the web folder client should = =20 > have been restored as it was shipped. > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dr. Frank Lowney=A0 frank.lowney@gcsu.edu > =A0=A0=A0 Director, Electronic Instructional Services, a unit of the > =A0=A0=A0 Office of Information and Instructional Technology, > =A0=A0=A0 Professional Pages: http://www.gcsu.edu/oiit/eis/ > =A0=A0=A0 Personal Pages: http://www.faculty.de.gcsu.edu/~flowney > Voice: (478) 445-5260 > NOTICE: Please be advised that I am hearing impaired and communicate =20= > most effectively via e-mail.=A0 Follow-up summaries of telephone =20 > conversations by e-mail are most appreciated. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > We don't make instruction effective, we make effective instruction =20 > more accessible. From w3c-dist-auth-request@w3.org Thu Dec 9 19:05:18 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00224 for ; Thu, 9 Dec 2004 19:05:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcYGO-0001ny-S9 for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 00:04:00 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CcYGM-0001nK-QS for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 00:03:58 +0000 Received: from cats-mx4.ucsc.edu ([128.114.125.37]) by bart.w3.org with esmtp (Exim 4.34) id 1CcYGM-0002gx-IQ for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 00:03:58 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx4.ucsc.edu (8.13.1/8.13.1) with ESMTP id iBA03Aov016857 for ; Thu, 9 Dec 2004 16:03:13 -0800 (PST) Message-Id: <200412100003.iBA03Aov016857@cats-mx4.ucsc.edu> Reply-To: From: "Jim Whitehead" To: Date: Thu, 9 Dec 2004 16:03:02 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200412060313.iB63D2qg017145@ietf.cse.ucsc.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTbQYvqThaWpyKqQfWQ8jrAzVpr1QDCN6Zg X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 70] New: REBIND arguments are like BIND X-Archived-At: http://www.w3.org/mid/200412100003.iBA03Aov016857@cats-mx4.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9172 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 00:04:00 +0000 Content-Transfer-Encoding: 7bit Geoff Clemm writes: > The REBIND method was intended to have syntax that paralleled > BIND. This means that the request-URL is the collection into > which the binding is being created, the segment in the body > is the new binding name in the request-URL collection, and > the href in the body is the "source", i.e. the resource that > is being rebound. > > The recent edits in this section (intended to address Jim's > observation that the meaning of arguments of the method were > not underspecified) were incorrect and broke this. In > particular, the introductory sentences of REBIND should be > modeled after BIND, and the precondition names (which were > originally correct) should be restored. Do we care that the parameters are now switched as compared to those of MOVE? Source Destination MOVE Request-URI Destination header REBIND href XML elem Request-URI plus segment XML elem I think it doesn't matter, but thought I should raise it. - Jim From w3c-dist-auth-request@w3.org Thu Dec 9 19:13:57 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00669 for ; Thu, 9 Dec 2004 19:13:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcYPJ-0004Y4-UO for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 00:13:13 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CcYPJ-0004XC-Do for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 00:13:13 +0000 Received: from cats-mx1.ucsc.edu ([128.114.125.34]) by bart.w3.org with esmtp (Exim 4.34) id 1CcYPI-00057Q-Je for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 00:13:12 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx1.ucsc.edu (8.13.1/8.13.1) with ESMTP id iBA0CcEW016229 for ; Thu, 9 Dec 2004 16:12:41 -0800 (PST) Message-Id: <200412100012.iBA0CcEW016229@cats-mx1.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Thu, 9 Dec 2004 16:12:30 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200412031732.iB3HWPbU026871@cats-mx3.ucsc.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcTYvj15gVrLWWUARoivMkk9zwTkogAnrgwgATsUsDA= X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: REBIND and lock token submission example X-Archived-At: http://www.w3.org/mid/200412100012.iBA0CcEW016229@cats-mx1.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9173 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 00:13:13 +0000 Content-Transfer-Encoding: 7bit OK, here is a suggested examples for REBIND and lock token submission: Before: +------------------+ | Root Collection | | bindings: | | CollW | +------------------+ | | | +-------------------------------+ | Collection C1 |<--------+ | LOCKED infinity | | | (lock token L1) | | | bindings: | | | CollX CollY | | +-------------------------------+ | | | | | | (creates loop) | | | | +-----------------+ +------------------+ | | Collection C2 | | Collection C3 | | | (inherit lock) | | (inherit lock) | | | (lock token L1) | | (lock token L1) | | | bindings: | | bindings: | | | {none} | | y.gif CollZ | | +-----------------+ +------------------+ | | | | | +-----+ | +---------------------------+ | Resource R2 | | (lock inhereited from C1) | | (lock token L1) | +---------------------------+ After: +------------------+ | Root Collection | | bindings: | | CollW | +------------------+ | | | +-------------------------------+ | Collection C1 | | LOCKED infinity | | (lock token L1) | | bindings: | | CollX CollY | +-------------------------------+ | ^ | | | | +-----------------+ | +------------------+ | Collection C2 | | | Collection C3 | |(inherited lock) | | | (inherited lock) | |(lock token L1) | | | (lock token L1) | | bindings: | | | bindings: | | CollA | | | y.gif | +-----------------+ | +------------------+ | | | +---------------+ | (creates loop) | +---------------------------+ | Resource R2 | | (inherited lock from C1) | | (lock token L1) | +---------------------------+ Should only involve passing lock token L1 in the If header of the REBIND. - Jmi From w3c-dist-auth-request@w3.org Thu Dec 9 20:07:21 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05326 for ; Thu, 9 Dec 2004 20:07:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcZDi-0002he-34 for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 01:05:18 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CcZDh-0002h5-Ma for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 01:05:17 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by bart.w3.org with esmtp (Exim 4.34) id 1CcZDh-00070g-Em for w3c-dist-auth@w3c.org; Fri, 10 Dec 2004 01:05:17 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Dec 2004 17:04:39 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200412061915.iB6JErCF012946@cats-mx3.ucsc.edu> References: <200412061915.iB6JErCF012946@cats-mx3.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <77EAC42D-4A47-11D9-8831-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit From: Brian Korver Date: Thu, 9 Dec 2004 17:04:39 -0800 To: "'Webdav WG'" X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 10 Dec 2004 01:04:39.0908 (UTC) FILETIME=[39A6FA40:01C4DE54] Received-SPF: none (bart.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/77EAC42D-4A47-11D9-8831-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9174 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 01:05:18 +0000 Content-Transfer-Encoding: 7bit I strongly agree that text like this -- text that explains the rough consensus on how properties interact with bindings -- should appear in the bind spec (ignoring whether or not this exact text represents the rough consensus). -brian briank@xythos.com On Dec 6, 2004, at 11:14 AM, Jim Whitehead wrote: > > I think it would be good to include the following language in the bind > specification: > > Note that, consistent with [RFC2518], the value of a dead property is > independent of the number of bindings to its host resource, and of the > path > submitted to PROPFIND. Since live properties can be aribtrary > computational > processes, they MAY vary depending on path or number of bindings, but > SHOULD > NOT do this unless the definition of the live property explicitly > includes > this dependency. > > > Here I avoided adding new requirements in areas already covered by > 2518, but > did add requirements for the new situation raised by the BIND > specification. > > - Jim > >> -----Original Message----- >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Lisa Dusseault >> Sent: Monday, December 06, 2004 10:56 AM >> To: Julian Reschke >> Cc: Webdav WG >> Subject: Re: [Bug 3] Bindings draft should specify if all >> properties MUST have same value on all bindings >> >> >> I don't think everybody else agrees that there is no problem. >> I have only heard a couple people directly address this issue. >> >> The last time we discussed this (this fall but also way >> earlier), we did come to rough consensus that properties, >> even live properties, must have the same value no matter >> which binding is used to request the value of the property. >> (I am not sure I agree with the conclusion, but I agree there >> was rough consensus.) >> >> Now I'm saying that it's not clear in the spec that this is >> required and we should put it in the spec. This is a >> different issue (what should be in the spec) than the >> previous issue ( what should be >> allowed) although clearly one follows from the other. In >> the message >> you point to, Geoff and Jason and yourself addressed the >> "what should be allowed" issue. Now let's discuss "what >> should be in the spec". >> >> Lisa >> >> On Dec 6, 2004, at 10:26 AM, Julian Reschke wrote: >> >>> Lisa Dusseault wrote: >>>> This bug/issue has been repeatedly closed "worksforme". I do not >>>> agree that the issue is closed. What is our model for >> whether a bug >>>> can be closed or not? >>> >>> Well, it has also been re-opened, with which *I* don't agree. What >>> does this tell us? BugZilla is just a tool for keeping track of >>> issues, but it does not help defining rough consensus. >>> >>> As stated before, a situation where a single voice continues to >>> re-raise the same issue, but everybody else appears to agree that >>> there is no problem, seems to be exactly the case where the term >>> "rough consensus" applies. >>> >>> See also >>> >> 0025.html>. >>> >>> Best regards, Julian >>> >>> -- >>> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >> > > > From w3c-dist-auth-request@w3.org Thu Dec 9 20:10:24 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05839 for ; Thu, 9 Dec 2004 20:10:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcZI0-00048T-EI for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 01:09:44 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CcZI0-00047p-3Q for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 01:09:44 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by bart.w3.org with esmtp (Exim 4.34) id 1CcZHz-0000v9-P2 for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 01:09:43 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Dec 2004 17:09:12 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41B70863.2030007@gmx.de> References: <200412080015.iB80FWsp016173@cats-mx4.ucsc.edu> <41B70863.2030007@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A3708DC-4A48-11D9-8831-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit From: Brian Korver Date: Thu, 9 Dec 2004 17:09:12 -0800 To: "'webdav'" X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 10 Dec 2004 01:09:12.0158 (UTC) FILETIME=[DBED07E0:01C4DE54] Received-SPF: none (bart.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/1A3708DC-4A48-11D9-8831-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9175 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 01:09:44 +0000 Content-Transfer-Encoding: 7bit Julian, Ok, we know your vote for how live properties interact with bindings (as if we didn't know already ;-), but I think that in combination with Jim's point underscores the need for explicit text in the bind spec. -brian briank@xythos.com On Dec 8, 2004, at 5:57 AM, Julian Reschke wrote: > > Jim Whitehead wrote: >> Seems to me we already have an example of a live property that varies >> depending on the binding used to access it -- DAV:displayname. On >> servers >> where this just reflects the binding name of the resource, it seems >> like it >> would vary depending on the binding used to access it. > > This is a known issue with servers that indeed implement > DAV:displayname that way; for instance discussed in > issues.html#bind_properties>. > > My position is, that a server that implements DAV:displayname as > computed property based on the binding name is simply poorly > implemented; DAV:displayname is defined to be "...a description of the > resource that is suitable for presentation to a user" > ( rfc2518.html#PROPERTY_displayname>), not a repetition of the last path > segment. > > Apache/moddav and many other serves get this right; and I expect the > same will apply to any server that actually supports multiple > bindings. > > Best regards, Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Thu Dec 9 20:48:55 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08498 for ; Thu, 9 Dec 2004 20:48:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcZt2-0001a6-0y for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 01:48:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CcZt0-0001ZI-8x; Fri, 10 Dec 2004 01:47:58 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by lisa.w3.org with esmtp (Exim 4.34) id 1CcZss-0000ye-Rq; Fri, 10 Dec 2004 01:47:50 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iBA1lQv5029407; Thu, 9 Dec 2004 20:47:26 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iBA1lQx8266464; Thu, 9 Dec 2004 20:47:26 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iBA1lPXn019940; Thu, 9 Dec 2004 20:47:26 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iBA1lPZE019937; Thu, 9 Dec 2004 20:47:25 -0500 In-Reply-To: <200412100003.iBA03Aov016857@cats-mx4.ucsc.edu> To: Cc: w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 9 Dec 2004 20:47:23 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/09/2004 20:47:24, Serialize complete at 12/09/2004 20:47:24 Content-Type: multipart/alternative; boundary="=_alternative 0009D4F685256F66_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 70] New: REBIND arguments are like BIND X-Archived-At: http://www.w3.org/mid/OF583D85E0.911864C4-ON85256F66.0009BBAE-85256F66.0009D4F8@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9176 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 01:48:00 +0000 This is a multipart message in MIME format. --=_alternative 0009D4F685256F66_= Content-Type: text/plain; charset="US-ASCII" I think the consistency of REBIND with BIND is more important than the consistency with MOVE. Cheers, Geoff Jim wrote on 12/09/2004 07:03:02 PM: > > Geoff Clemm writes: > > > The REBIND method was intended to have syntax that paralleled > > BIND. This means that the request-URL is the collection into > > which the binding is being created, the segment in the body > > is the new binding name in the request-URL collection, and > > the href in the body is the "source", i.e. the resource that > > is being rebound. > > > > The recent edits in this section (intended to address Jim's > > observation that the meaning of arguments of the method were > > not underspecified) were incorrect and broke this. In > > particular, the introductory sentences of REBIND should be > > modeled after BIND, and the precondition names (which were > > originally correct) should be restored. > > Do we care that the parameters are now switched as compared to those of > MOVE? > > Source Destination > > MOVE Request-URI Destination header > > REBIND href XML elem Request-URI plus segment > XML elem > > > I think it doesn't matter, but thought I should raise it. > > - Jim > > --=_alternative 0009D4F685256F66_= Content-Type: text/html; charset="US-ASCII"
I think the consistency of REBIND with BIND is more important
than the consistency with MOVE.

Cheers,
Geoff


Jim wrote on 12/09/2004 07:03:02 PM:

>
> Geoff Clemm writes:
>
> > The REBIND method was intended to have syntax that paralleled
> > BIND.  This means that the request-URL is the collection into
> > which the binding is being created, the segment in the body
> > is the new binding name in the request-URL collection, and
> > the href in the body is the "source", i.e. the resource that
> > is being rebound.
> >
> > The recent edits in this section (intended to address Jim's
> > observation that the meaning of arguments of the method were
> > not underspecified) were incorrect and broke this.  In
> > particular, the introductory sentences of REBIND should be
> > modeled after BIND, and the precondition names (which were
> > originally correct) should be restored.
>
> Do we care that the parameters are now switched as compared to those of
> MOVE?
>
>            Source            Destination
>
> MOVE     Request-URI         Destination header
>
> REBIND   href XML elem     Request-URI plus segment
>                              XML elem
>
>
> I think it doesn't matter, but thought I should raise it.
>
> - Jim
>
>
--=_alternative 0009D4F685256F66_=-- From w3c-dist-auth-request@w3.org Fri Dec 10 03:44:27 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23997 for ; Fri, 10 Dec 2004 03:44:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcgM1-0003tB-Nx for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 08:42:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CcgLz-0003s8-DF for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 08:42:19 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1CcgLr-0001do-Ns for w3c-dist-auth@w3c.org; Fri, 10 Dec 2004 08:42:12 +0000 Received: (qmail 18098 invoked by uid 65534); 10 Dec 2004 08:41:46 -0000 Received: from p54856FE9.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.111.233) by mail.gmx.net (mp012) with SMTP; 10 Dec 2004 09:41:46 +0100 X-Authenticated: #1915285 Message-ID: <41B9613F.1050606@gmx.de> Date: Fri, 10 Dec 2004 09:41:35 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: "'Webdav WG'" References: <200412061915.iB6JErCF012946@cats-mx3.ucsc.edu> <77EAC42D-4A47-11D9-8831-000A95AACED2@xythos.com> In-Reply-To: <77EAC42D-4A47-11D9-8831-000A95AACED2@xythos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41B9613F.1050606@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9177 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 08:42:21 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > > I strongly agree that text like this -- text that explains the rough > consensus on how properties interact with bindings -- should appear > in the bind spec (ignoring whether or not this exact text represents > the rough consensus). > ... Well, the main issue is that we don't have "rough consensus" yet (and when we have, that should be added as to-do for RFC2518bis). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 10 03:44:54 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24038 for ; Fri, 10 Dec 2004 03:44:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcgNv-0004u9-0w for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 08:44:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CcgNu-0004sz-4X for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 08:44:18 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CcgNl-0002EF-UV for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 08:44:10 +0000 Received: (qmail 30861 invoked by uid 65534); 10 Dec 2004 08:43:45 -0000 Received: from p54856FE9.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.111.233) by mail.gmx.net (mp006) with SMTP; 10 Dec 2004 09:43:45 +0100 X-Authenticated: #1915285 Message-ID: <41B961BD.3090206@gmx.de> Date: Fri, 10 Dec 2004 09:43:41 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: w3c-dist-auth@w3.org References: <200412100003.iBA03Aov016857@cats-mx4.ucsc.edu> In-Reply-To: <200412100003.iBA03Aov016857@cats-mx4.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 70] New: REBIND arguments are like BIND X-Archived-At: http://www.w3.org/mid/41B961BD.3090206@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9178 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 08:44:19 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Geoff Clemm writes: > > >>The REBIND method was intended to have syntax that paralleled >>BIND. This means that the request-URL is the collection into >>which the binding is being created, the segment in the body >>is the new binding name in the request-URL collection, and >>the href in the body is the "source", i.e. the resource that >>is being rebound. >> >>The recent edits in this section (intended to address Jim's >>observation that the meaning of arguments of the method were >>not underspecified) were incorrect and broke this. In >>particular, the introductory sentences of REBIND should be >>modeled after BIND, and the precondition names (which were >>originally correct) should be restored. > > > Do we care that the parameters are now switched as compared to those of > MOVE? > > Source Destination > > MOVE Request-URI Destination header > > REBIND href XML elem Request-URI plus segment > XML elem > > > I think it doesn't matter, but thought I should raise it. REBIND is different from MOVE anyway (by design). Making it consistent with BIND then makes a lot of sense. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 10 11:17:15 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26686 for ; Fri, 10 Dec 2004 11:17:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcnQg-0003dj-Nh for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 16:15:38 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CcnQe-0003YE-6P for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 16:15:36 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CcnQd-0002F7-Io for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 16:15:35 +0000 Received: (qmail 27953 invoked by uid 65534); 10 Dec 2004 16:15:02 -0000 Received: from p54856FE9.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.111.233) by mail.gmx.net (mp006) with SMTP; 10 Dec 2004 17:15:02 +0100 X-Authenticated: #1915285 Message-ID: <41B9CB79.5060408@gmx.de> Date: Fri, 10 Dec 2004 17:14:49 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412100012.iBA0CcEW016229@cats-mx1.ucsc.edu> In-Reply-To: <200412100012.iBA0CcEW016229@cats-mx1.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: REBIND and lock token submission example X-Archived-At: http://www.w3.org/mid/41B9CB79.5060408@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9179 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 16:15:38 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > OK, here is a suggested examples for REBIND and lock token submission: > > Before: > > +------------------+ > | Root Collection | > | bindings: | > | CollW | > +------------------+ > | > | > | > +-------------------------------+ > | Collection C1 |<--------+ > | LOCKED infinity | | > | (lock token L1) | | > | bindings: | | > | CollX CollY | | > +-------------------------------+ | > | | | > | | (creates loop) | > | | | > +-----------------+ +------------------+ | > | Collection C2 | | Collection C3 | | > | (inherit lock) | | (inherit lock) | | > | (lock token L1) | | (lock token L1) | | > | bindings: | | bindings: | | > | {none} | | y.gif CollZ | | > +-----------------+ +------------------+ | > | | | > | +-----+ > | > +---------------------------+ > | Resource R2 | > | (lock inhereited from C1) | > | (lock token L1) | > +---------------------------+ > > After: > > +------------------+ > | Root Collection | > | bindings: | > | CollW | > +------------------+ > | > | > | > +-------------------------------+ > | Collection C1 | > | LOCKED infinity | > | (lock token L1) | > | bindings: | > | CollX CollY | > +-------------------------------+ > | ^ | > | | | > +-----------------+ | +------------------+ > | Collection C2 | | | Collection C3 | > |(inherited lock) | | | (inherited lock) | > |(lock token L1) | | | (lock token L1) | > | bindings: | | | bindings: | > | CollA | | | y.gif | > +-----------------+ | +------------------+ > | | | > +---------------+ | > (creates loop) | > +---------------------------+ > | Resource R2 | > | (inherited lock from C1) | > | (lock token L1) | > +---------------------------+ > > > Should only involve passing lock token L1 in the If header of the REBIND. OK, so this would be either MOVE /CollW/CollY/CollZ HTTP/1.1 Destination: /CollW/CollX/CollA If: () or REBIND /CollW/CollX HTTP/1.1 If: () Content-Type: application/xml CollA /CollW/CollY/CollZ Do we have consensus to add this example at all? If so, would it make sense to *replace* the REBIND example we already have in section 6.1 ()? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 10 11:53:32 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28971 for ; Fri, 10 Dec 2004 11:53:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cco0Y-00044S-Hz for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 16:52:42 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cco0Y-00042Z-6t for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 16:52:42 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cco0X-0002FW-4n for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 16:52:41 +0000 Received: (qmail 11769 invoked by uid 65534); 10 Dec 2004 16:52:09 -0000 Received: from p54856FE9.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.111.233) by mail.gmx.net (mp027) with SMTP; 10 Dec 2004 17:52:09 +0100 X-Authenticated: #1915285 Message-ID: <41B9D42F.7040609@gmx.de> Date: Fri, 10 Dec 2004 17:51:59 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'WebDAV (WebDAV WG)'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: status of BIND issue 2.6_when_do_ids_change X-Archived-At: http://www.w3.org/mid/41B9D42F.7040609@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9180 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 16:52:42 +0000 Content-Transfer-Encoding: 7bit Hi, here's a leftover (I made a change, but I didn't get back any feedback about whether I can close the issue): Jim, you raised the issue, could you please advise how to proceed with it? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 10 13:17:29 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04089 for ; Fri, 10 Dec 2004 13:17:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcpJW-0003kC-9Z for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 18:16:22 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CcpJU-0003jN-Qz for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 18:16:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CcpJU-0008Bp-Ja for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 18:16:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iBAIGJ0Y003262; Fri, 10 Dec 2004 10:16:19 -0800 Date: Fri, 10 Dec 2004 10:16:19 -0800 Message-Id: <200412101816.iBAIGJ0Y003262@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/200412101816.iBAIGJ0Y003262@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9181 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 18:16:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-10 10:16 ------- Seems that we have settled the first of Jim's issues (). What about the second one? I'm not sure here what the issue is... Adding a new binding to a (previously non-locked) collection binding below a depth:infinity locked resource will cause the collection and all it's members to become part of the lock as well. Do you feel we should include an example for this? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Dec 10 13:30:34 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05141 for ; Fri, 10 Dec 2004 13:30:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcpWR-0007Op-Qb for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 18:29:43 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CcpWR-0007OG-JK for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 18:29:43 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CcpWR-0004Fx-7m for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 18:29:43 +0000 Received: (qmail 20056 invoked by uid 65534); 10 Dec 2004 18:29:11 -0000 Received: from p54856FE9.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.111.233) by mail.gmx.net (mp010) with SMTP; 10 Dec 2004 19:29:11 +0100 X-Authenticated: #1915285 Message-ID: <41B9EAEA.8030007@gmx.de> Date: Fri, 10 Dec 2004 19:28:58 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'webdav'" References: <200412090012.iB90CZKX014846@cats-mx4.ucsc.edu> In-Reply-To: <200412090012.iB90CZKX014846@cats-mx4.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41B9EAEA.8030007@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9182 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 18:29:43 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > ... > > There's nothing in 2518 that implies a live property's computation depends > only on the state of the resource. It would be prefectly valid to have a > live property that returned a random number. : "Properties are pieces of data that describe the state of a resource. Properties are data about data." Also note that aforementioned live property wouldn't *vary* by binding; it would just be random. What I'm looking for is a use-case where properties varying by *binding* really make sense. So far, I'm not aware of any case where this wouldn't be better modelled as a property on the collection holding the binding. > I'm not too worried about encouraging binding-specific properties, as I > believe implementors would be able to see the potential usability drawbacks > of such properties. I tend to disagree here (judging from previous reactions) :-) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 10 14:43:15 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10041 for ; Fri, 10 Dec 2004 14:43:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcqeB-0004ba-M3 for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 19:41:47 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ccqe9-0004aZ-Tn for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 19:41:45 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1Ccqe9-0005aW-6z for w3c-dist-auth@w3c.org; Fri, 10 Dec 2004 19:41:45 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBAJfUaa013611 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 10 Dec 2004 11:41:32 -0800 Mime-Version: 1.0 (Apple Message framework v619) To: Webdav WG Message-Id: <79840EB3-4AE3-11D9-AC43-000A95B2BB72@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-15--153567437 From: Lisa Dusseault Date: Fri, 10 Dec 2004 11:41:24 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Fwd: Proceedings from WebDAV from IETF-61 X-Archived-At: http://www.w3.org/mid/79840EB3-4AE3-11D9-AC43-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9183 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 19:41:47 +0000 --Apple-Mail-15--153567437 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit FYI Begin forwarded message: > From: Joe Hildebrand > Date: December 10, 2004 10:26:59 AM PST > To: proceedings@ietf.org > > > WebDAV IETF 61 > Washington, DC > 2004-11-11 > > Agenda > ------ > - Agenda Bash > - Process > - Bugzilla issue tracking: > http://ietf.webdav.org:8080/bugzilla/ > - Closing issues > - BIND > - Redirect > - QUOTA > - CalDAV > - WebDAV events > > (http://www.jabber.org/~stpeter/ietf/draft-hildebrand-webdav-notify > -00.html) > - PATCH > > > > (11:07:59) Julian Reschke: Jim: I agree that RFC2518bis should > integrate all clarifications that are needed to explain behaviour in > presence of multiple bindings. For simplicity, I'd still prefer to > leave authorabilty of new bindings for a separate doc. > (11:08:02) lisa: It did mention a few possibilities, like the > possibility for multiple bindings, but that doesn't mean it really > "defined" bindings. > (11:08:22) ***pguenther is playing the role of note taker > (11:08:39) pguenther: agenda bashing: add a calDAV report > (11:08:43) pguenther: (at end) > (11:08:44) Jim Whitehead: Thanks pguenther > (11:08:59) hardie: We have agreed that CalDAV is the correct > orthography, too, so score! > (11:09:22) lisa: http://ietf.webdav.org:8080/bugzilla > (11:09:43) pguenther: bugzilla is set up, report problems to Joe > (11:10:06) pguenther: is the *canonical* repository for issues > (11:10:22) pguenther: authors cannot close issues, only chairs > (11:10:40) Jim Whitehead: how many people in the room in DC? > (11:10:59) MatthewElvey entered the room. > (11:11:06) pguenther: 8 + ADs + chairs > (11:11:11) bdesruisseaux entered the room. > (11:11:14) Jim Whitehead: thx > (11:11:20) Julian Reschke: bugzilla: I think this needs to cc the > mailing list (I know Lisa and Joe have been working on it; but it > doesn't seem to work right now) > (11:11:41) pguenther: right, Joe is still aiming towards that > (11:11:43) Jim Whitehead: i received a few emails recently. think this > integration is working > (11:11:49) pguenther: sorry, slipped past my typing > (11:12:11) pguenther: Julian sent in update on Bind > (11:12:19) pguenther: WGLC on it soon > (11:12:41) Julian Reschke: (no mails visibile on > http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/) > (11:12:55) Jim Whitehead: what is the plan for resolving open BIND > issues and getting to WGLC? > (11:12:55) pguenther: Lisa, as Julian: no open issues > (11:13:21) pguenther: Lisa, as Lisa: some items found and put in > bugzilla > (11:13:45) codebear entered the room. > (11:13:46) Julian Reschke: These issues IMHO are the same we already > discussed on the mailing list. > (11:14:00) Jim Whitehead: so do you think they're open or closed? > (11:14:09) pguenther: moving on to Redirect: Julian: "Redirect to move > forwards after BIND" > (11:14:22) Julian Reschke: Discussion ended with consensus (as far as > I can tell), if that's incorrect we'll need to restart it on the ML. > (11:14:24) pguenther: Joe doesn't think there are any dependencies, > just a matter of work > (11:14:33) hildjj: Is that correct? > (11:14:40) Julian Reschke: Yes. > (11:14:59) Julian Reschke: There is one main issue left for which I'd > appreciate feedback, which is... > (11:15:03) Jim Whitehead: so, will there be one more I-D then WGLC, or > are we going directly to WGLC? > (11:15:07) lisa: I think redirect is closer to WGLC, personally > (11:15:09) Jim Whitehead: on BIND that is > (11:15:25) Julian Reschke: ...documented here: > http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0180.html > (11:15:26) lisa: redirect closer to WGLC than Bindings, to be clear > (and both of those closer than RFC2518bis) > (11:15:36) hildjj: Jim: WGLC on this issue, as soon as we get Bugzilla > 100% > (11:15:43) hildjj: issue/version > (11:15:57) Jim Whitehead: bugzilla 100% means all issues reolved? > (11:16:07) Julian Reschke: IMHO redirect indeed *has* open issues that > need to be resolved before we can go to LC. > (11:17:00) lisa: Yes Julian, that could be, but redirct has fewer > issues and easier to resolve -- that's just my guess, based on the > issues I'm aware of. > (11:17:38) Jim Whitehead: wouldn't surprise me if that's the case -- > redirect has fewer impacts on the rest of the DAV data model > (11:18:00) lisa: that's right > (11:18:07) Julian Reschke: I personally think that BIND is a litmus > test about whether this WG is still functional or not. It has been in > almost-last-call state for over 19 months, and it's on top of our prio > list. Let's do not move other things in front of it. > (11:19:14) pguenther: discussion: delete of redirection is the > important case, which makes #1 choice preferable > (11:19:27) pguenther: (or rather, the _really_ important case) > (11:20:32) pguenther: Julian: Joe agrees with the sentiment of your > concern over BIND and reordering the submission of the drafts > (11:21:59) Julian Reschke: Meta: BIND is stable and has been > implemented in various servers, while REDIRECT currently seems to be > implemented by one single server (ours). Thus, the WG should keep BIND > as #1 prio. > (11:22:03) Jim Whitehead: i don't have a strong preference over which > one is finished first -- obviously want to see both completed > (11:22:05) pguenther: Ted (Hardie) to submit to bugzilla an issue over > DELETE of a redirection not being explicitly described/warned > about/pointed out > (11:23:00) pguenther: moving on to QUOTA > (11:23:07) pguenther: new draft submitted > (11:23:15) lisa: Julian, it would be great to get a snapshot of the > implementation status of BIND and REDIRECT, on the WG list. > (11:23:25) pguenther: big change: removed 'authorable' property that > was causing the most grief > (11:23:44) pguenther: handful of nits (Thanks Julian!) > (11:24:45) pguenther: suggestions to reorganize seem style issues and > will be left to author > (11:24:55) pguenther: WGLC real soon > (11:25:02) pguenther: CalDAV notes > (11:25:15) Jim Whitehead: I asked brian when a new draft would be > created, haven't received a response. Would be good for him to receive > some WG Chair direction on this > (11:25:32) lisa: Brian just said, in the next week or so after he gets > back from DC. > (11:25:32) hildjj: brian says soon after he gets back. > (11:25:35) lisa: heh > (11:25:40) pguenther: calendaring roundtable was held > (11:25:54) pguenther: added new resources and properties > (11:26:21) pguenther: fourth draft adds new method 'add calender' > (11:26:34) lisa: literally "MKCALENDAR" > (11:27:09) pguenther: reached concensus over changes and are working > on searches and some specific calendaring functions > (11:27:21) lisa: It would be good to get broader feedback on our > CalDAV ideas about property promotion... > (11:27:59) lisa: it adds complexity (since we know we want to support > access via iCalendar formatted bodies, anyway) but we're discussing > whether the benefits outweigh that. > (11:28:07) pguenther: property promotion as means to provide better > searching including partial retrieval(?) > (11:28:55) lisa: Yep -- better searching, partial retrieval, partial > write. To change the DTSTART of an iCalendar body, the client must > upload the whole body again. Unless we reflect the body's DTSTART > value as a WebDAV property, in which case you could PROPPATCH only > that property. > (11:28:57) pguenther: discussion on promotion > (11:29:32) Jim Whitehead: it certainly seems to me that calendar > searching will be critical for making CalDAV interesting for > Enterprise deployment. > (11:29:53) lisa: Yes but SEARCH+basicsearch can't even meet the > requirements. > (11:30:19) Jim Whitehead: Doesn't surprise me -- will undoubtedly > require a specific CaLDAV search vocabulary > (11:30:30) pguenther: timezone as example of why a brute force > renaming with separator isn't always good > (11:30:32) lisa: yep -- expanding recurrances, time-range results, etc. > (11:31:04) pguenther: use reports to do stuff beyond the capabilities > of search > (11:31:16) pguenther: what is being optimized for? > (11:31:28) pguenther: smarts in server or client? > (11:31:31) Jim Whitehead: Will also need a richer notion of principal > than is provided by ACL spec -- will be tricky to stay away from an > entire directory server capability > (11:31:42) lisa: Why is that, Jim? > (11:31:44) pguenther: shifted in calsch WG over time > (11:32:03) pguenther: (where the smarts were expected to be, that is) > (11:32:04) Jim Whitehead: True, REPORT would be very handy here. Trick > is figuring out which REPORTs to support > (11:32:45) Jim Whitehead: Principals in ACL spec don't have enough > metadata (phone number, room number, etc.) -- no problem to add these, > just need to have standard property lists > (11:33:57) pguenther: searching and filtering take place on the server > side, with knowledge of recurrence[sic] rules > (11:34:02) lisa: We may only need one more principal property for > CalDAV -- "calendar URL(s)" > (11:34:13) lisa: the rest of the information can be properties on the > calendar resources, I think > (11:34:14) pguenther: servers _are_ being expected to understand the > semantics of the objects > (11:35:04) Jim Whitehead: For example, Oracle Calendar allows you to > associate "organizations" to specific principals, you you can > differentiate between the Nguyen in development and the Nguyen in > accounting. > (11:35:14) pguenther: that an assumption of several things, including > promotion (but that may be doable with a shim), and recurrence > (11:35:26) pguenther: the latter being critical to calendaring > (11:35:49) lisa: Joe just realized he should add the webdav event > stuff to the agenda... > (11:38:08) pguenther: Oracle hoping to have basic IOP by mid January > (11:38:58) Jim Whitehead: expand "IOP" please? > (11:39:19) pguenther: sorry, have it in operation > (11:39:32) pguenther: (short between ears and fingers) > (11:39:36) Jim Whitehead: OK, what are they hoping to have in > operation? CalDAV? > (11:39:47) Jim Whitehead: Or have we moved on to events? > (11:39:53) pguenther: yes, with searching > (11:40:05) pguenther: "what meeting have I not responded to" etc > (11:40:12) lisa: Joe mentioned the HTTP header registry, which Mark > Nottingham is working on > (11:40:24) lisa: IOP is "interoperability" > (11:40:57) lisa: Some CalDAV features should interoperate in mid-Jan. > (11:41:11) Jim Whitehead: Also, shameless plug: there will be an > article on WebDAV in the Jan/Feb issue of IEEE Internet Computing. > Will focus on the ACL specification > (11:41:31) Jim Whitehead: How can you have interop when the spec isn't > complete yet? > (11:41:46) bdesruisseaux: The CalDAV protocol adapter of Oracle > Calendar should provide support for GET, PUT, DELETE, PROPFIND and > REPORTs to allow clients to create, modify, delete events as well as > search for them (with reports). > (11:41:54) Jim Whitehead: Or, put another way, what is the baseline > for this? > (11:42:12) Jim Whitehead: Is the CalDAV adapter going to be publically > available? > (11:42:27) pguenther: taking to list the details of having MKCAL > indicate what it is putting up > (11:42:33) Jim Whitehead: Who is the oracle contact for CalDAV? > (11:42:56) lisa: Bernard DesRuisseaux > (11:43:00) lisa: (in this room) > (11:43:04) bdesruisseaux: We'll make the adapter available outside our > firewall for CalDAV cllient initiative to work toward an IOP > (11:43:08) lisa: (both physical and jabber room) > (11:43:28) bdesruisseaux: Jim, I am the "dev" contact for CalDAV. > (11:43:51) Jim Whitehead: Super! Thanks Bernard. We're an oracle > calendar shop here at UCSC > (11:44:16) bdesruisseaux: Good! > (11:45:32) pguenther: Cyrus: no further immediate needs from CalDAV on > WebDAV; if stuff comes up during implementation then it will be taken > to the list > (11:46:21) pguenther: Bernard: in future, stuff like QUOTA may become > more important for CalDAV, to prevent DoS attacks in the direct case > of QUOTA > (11:46:30) Julian Reschke: If CalDAV in some way becomes an "official" > WebDAV working group item, I'd like to see discussions to actually > happen on the mailing list... > (11:46:48) Jim Whitehead: there are separate mailing lists for caldav > (11:46:58) Jim Whitehead: seems like it should be a separate WG in any > case > (11:47:07) Julian Reschke: Yes, but there seems to be a lot of > out-of-band dicussion :-) > (11:47:15) Jim Whitehead: :-) > 11:47:29) Jim Whitehead: not clear caldav folks want to be an IETF WG > (11:47:43) pguenther: for now, the CalDAV is expecting to stay as an > individual submission > (11:47:59) Julian Reschke: nothing wrong with that > (11:48:30) lisa: There are certainly a lot of out-of-band discussions. > Co-authors do that. > (11:48:35) lisa: :-) > (11:48:35) pguenther: Ted: HTTP SASL had a bunch of review comments > (11:48:39) Jim Whitehead: agreed > (11:49:12) lisa: I believe we're doing a good job of bringing the > out-of-band discussions on CalDAV into the spec and publishing it > frequently. > (11:49:17) pguenther: comments are currently unreplied to and is stuck > there until that happens, perhaps blocked on SASL WG > (11:49:17) pguenther: ? > (11:49:55) pguenther: Waiting on revision from Alexey based on review? > (11:50:06) pguenther: Lisa: blocked on disagreeing on how HTTP is > extensible > (11:51:35) pguenther: Lisa: a use case for HTTP SASL would help it > move forwards, perhaps > (11:51:42) lisa: Also blocked on understanding why it's needed > (11:52:02) pguenther: Cyrus/Ted: WebDAV pushing for HTTP SASL may serve > (11:52:29) lisa: (Scott could probably come up with a proposed model, > but he needs to be motivated by understanding "why SASL") > (11:52:34) lisa: (Scott Lawrence, that is) > (11:52:41) pguenther: Cyrus: webdav security considerations section, > etc > (11:52:55) pguenther: Moving on to events > (11:53:23) pguenther: Joe: "being that we're XMPP people, this > [events] is XMPP based" > (11:53:40) Jim Whitehead: Seems like HTTP/DAV is doing fine without > SASL. Would need to get buy-in from MSFT and Apache up front, > otherwise is DOA. Without this buy-in, seems like it's not worth our > time. > (11:53:57) Jim Whitehead: Is there an events specification out? > (11:54:06) Jim Whitehead: Or is this in the planning stages? > (11:54:28) pguenther: > http://www.jabber.org/~stpeter/ietf/dradft-saintandre-webdav-notify > -00.html > (11:54:35) Jim Whitehead: thx > (11:55:01) pguenther: JEP #60 (publish/subscribe protocol on top of > Jabber) > (11:55:10) pguenther: JEP == Jabber Enhancement Proposal > (11:55:20) pguenther: comes from Jabber Software Foundation > (11:55:49) pguenther: notify spec says how to use that spec to put on > top of it "this resouce was modified", perhaps also "here what was > changed" > (11:55:54) lisa: I've proposed we follow up HTTP SASL questions on the > HTTP list and see if we can get broader input there... Jim do you > still subscribe to that list? Can you point out the buy-in problem? > (11:56:09) pguenther: optional new property giving place to go for > changes > (11:56:17) Jim Whitehead: url is actually: > http://www.jabber.org/~stpeter/ietf/draft-hildebrand-webdav-notify > -00.html > (11:56:38) Jim Whitehead: I've never been on the SASL list, would be > willing to point out buy-in problem. > (11:56:43) lisa: thanks Jim! > (11:57:13) pguenther: (this was in revenge, stpeter on joe) > (11:57:17) lisa: There's not a specific SASL list... so I suggested > discussing HTTP SASL on ietf-http-wg@w3.org > (11:57:34) pguenther: Joe: does this ID deserve a home in WG > (11:57:35) lisa: I mean, there probably is a SASL list, but our > problem is not the SASL part of it. > (11:57:37) Jim Whitehead: ah, ok. yeah, that list is really quiet > (11:57:45) pguenther: Ted: isn't this also in atompub? > (11:57:45) Julian Reschke: yes, there is: http://www.imc.org/ietf-sasl/ > (11:57:53) pguenther: Joe: that's a different draft > (11:57:57) lisa: Our HTTP/SASL problem is how to extend HTTP in a > HTTP-like way, that works with intermediaries, to support SASL -- and > why to do so. > (11:58:03) Jim Whitehead: I can also contact authors directly. > (11:58:25) pguenther: Cyrus: security? how to do authentication? > (11:58:27) lisa: I've just asked Alexey Melnikov to try to kick off > discussion on mailto:ietf-http-wg@w3.org. > (11:58:38) pguenther: Joe: if you have SASL it's easy, and XMPP has > SASL > (11:58:38) Jim Whitehead: OK, why do we want SASL? I don't hear lots > of calls for replacing current SSL layer, and the CONNECT method isn't > getting lots of adoption AFAIK > (12:00:06) pguenther: Joe: they have a server that has separate "who's > allowed to publish" and "who's allowed to subscribe" > (12:01:38) pguenther: Joe: similarity to XMPP is nice; gives a dual > XMPP/WedDAV client ability to use the same creds/stuff to authentice > to both > (12:02:04) pguenther: Cyrus: similar to URLAUTH? > (12:02:11) pguenther: (from LEMONADE) > (12:02:34) pguenther: so called "pawn ticket" model: whoever has the > token can fetch resource > (12:02:37) Jim Whitehead: thx -- so the issue gets more important as > XMPP gains in adoption, and XMPP/DAV synergies become more useful > (12:03:08) pguenther: Lisa: old draft of this used by Lycos > (12:03:15) lisa: Not Lycos, Xythos :-) > (12:03:41) ***pguenther curses at the phenomes used by English > (12:03:57) pguenther: Jim: right > (12:04:51) lisa: Philip are you worried about Phonemes or Pheromones? > (12:05:30) ***pguenther curses at English in general > (12:05:36) pguenther: should never made it out of draft > (12:05:46) pguenther: Moving on to PATCH > (12:06:17) pguenther: Lisa: unable to register mime-type GDIF due to > issues with IPR > (12:06:35) pguenther: make VCDIF the required form? > (12:06:56) pguenther: but it can only be used in HTTP/1.1 according > to its IPR statement! > (12:07:08) Julian Reschke left the room (Replaced by new connection). > (12:07:08) Julian Reschke entered the room. > (12:07:09) Julian Reschke left the room. > (12:07:17) Julian Reschke entered the room. > (12:07:18) pguenther: there is not another diff format out there to use > (12:07:22) Jim Whitehead: don't understand IPR issue. MIME type > registration doesn't involve any exposure of IPR, as I recall > (12:07:35) pguenther: don't require diff format to be supported? > (12:07:48) Jim Whitehead: For example, MSFT still has complete control > over .doc format, but still has MIME type for it > (12:08:00) Julian Reschke: I think we'll need at least one simple diff > format that all severs and clients will support. > (12:08:11) pguenther: IANA won't register an application/* type > without resolution of IPR issues > (12:08:34) Julian Reschke: REQUIRING support for a format with unclear > IPR is problematic. > (12:08:48) Jim Whitehead: Agreed > (12:08:52) lisa: Yes, agreed. > (12:08:55) lisa: And then... ? > (12:09:05) Jim Whitehead: Subversion uses vdelta, but that also has a > patent on it > (12:10:09) pguenther: Ted: talk to Jeff Mogul? > (12:10:17) pguenther: Lisa: yes, he said use VCDIFF > (12:10:58) pguenther: suggestion to ask Jeff to lean on people to > update/extend IPR grant to apply to more uses including WebDAV > (12:11:00) Julian Reschke: I looked at VCDIFF a few weeks ago and it > seems to be way to complicated as a required base format. > (12:11:03) Jim Whitehead: Seems like we have three choices: (1) > explore where a common delta has RAND licensing (or owner is willing > to commit to RAND) (2) develop a new diff format that isn't patented > (hard, lots of IP in this space) (3) use a really old delta format > (like the Unix diff used in SCCS, or possibly even the diffs used in > RCS > (12:11:46) Jim Whitehead: There is also the XML diff format developed > by Vitali and Durand, called VTML > (12:12:01) Julian Reschke: Need to consider different use cases: text > patch (as in diff/patch) and binary patch (like when writing back only > parts of a binary resource) > (12:12:37) Julian Reschke: (the latter likely to be useful for clients > that map WebDAV to file I/O) > (12:12:54) Jim Whitehead: VTML URL is > http://www.cs.unibo.it/~fabio/bio/papers/1999/SCM99/SCM9.pdf > (12:13:02) lisa: There's also the XML diff format developed by Adrian > Mouat > (12:13:07) Jim Whitehead: Agreed VTML would be problematic for binary > diffs > (12:13:12) lisa: yup > (12:13:48) pguenther: Joe: regarding diff comments: "Can of worms; > move on for now" > (12:14:11) pguenther: Lisa: where to put content-type of patch in HTTP? > (12:14:32) Jim Whitehead: Seems to me we don't really need a > compressed diff format. Something that says insert n octets starting > at octet y, using encoding z would do the trick > (12:14:50) Julian Reschke: ...into the content-type header, as defined > in RFC2616... > (12:14:54) hildjj: Jim: that's gdiff, no? > (12:14:56) pguenther: long history of HTTP Content-Type and > "instance-Manipulation" headers > (12:15:23) Jim Whitehead: Don't know gdiff > (12:15:39) Julian Reschke: Yep, that's basically gdiff. > (12:16:04) pguenther: (i.e., can the content-type header be of the > underlying object, even when the actual body of the request is really > instruction to modify it) > (12:16:29) Julian Reschke: (http://www.w3.org/TR/NOTE-gdiff-19970901) > (12:16:34) pguenther: Joe: stuff is clearly still open; PATCH is not a > working group item > (12:16:42) Julian Reschke left the room (Replaced by new connection). > (12:16:43) Julian Reschke entered the room. > (12:16:43) Julian Reschke left the room. > (12:16:46) Jim Whitehead: Just looked at gdiff spec. Would be easy to > design something similar, but still markedly different > (12:16:47) Julian Reschke entered the room. > (12:16:52) Jim Whitehead: Does gdiff have IPR issues? > (12:17:04) lisa: Gdiff is not known not to have IPR issues. > (12:17:24) lisa: I submitted an IANA registration for > application/gdiff and it was rejected because IPR issues were not > clear. > (12:17:25) pguenther: Bernard: calendaring change format could be done > using diff format, so would be nice there too > (12:17:35) lisa: Joe > (12:17:41) lisa: Joe is declaring we're finished... > (12:17:47) hildjj: anything else before we're done? > (12:17:48) lisa: unless there are any last-minute issues > (12:18:11) pguenther: gavel has fallen > (12:18:18) hildjj: > (12:18:19) bdesruisseaux left the room. > (12:18:22) Julian Reschke: I'd like us as WG to agree that we > concentrate on the topics that are on top of our charter. > (12:18:37) hildjj: Julian: yes. BIND first. > (12:19:04) Jim Whitehead: OK > (12:19:16) hildjj left the room. > (12:19:16) Julian Reschke: People who do have open issues with the > latest draft, *please* post them to the ML for dicussion. > (12:19:50) Jim Whitehead: OK > (12:25:41) hardie left the room (Disconnected). > (12:25:57) codebear left the room. > (12:26:20) Julian Reschke left the room (Disconnected). > > > -- > Joe Hildebrand > Denver, CO, USA > --Apple-Mail-15--153567437 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit FYI Begin forwarded message: 0000,0000,0000From: Joe Hildebrand < 0000,0000,0000Date: December 10, 2004 10:26:59 AM PST 0000,0000,0000To: proceedings@ietf.org < WebDAV IETF 61 Washington, DC 2004-11-11 Agenda ------ - Agenda Bash - Process - Bugzilla issue tracking: http://ietf.webdav.org:8080/bugzilla/ - Closing issues - BIND - Redirect - QUOTA - CalDAV - WebDAV events (http://www.jabber.org/~stpeter/ietf/draft-hildebrand-webdav-notify-00.html) - PATCH < < (11:07:59) Julian Reschke: Jim: I agree that RFC2518bis should integrate all clarifications that are needed to explain behaviour in presence of multiple bindings. For simplicity, I'd still prefer to leave authorabilty of new bindings for a separate doc. (11:08:02) lisa: It did mention a few possibilities, like the possibility for multiple bindings, but that doesn't mean it really "defined" bindings. (11:08:22) ***pguenther is playing the role of note taker (11:08:39) pguenther: agenda bashing: add a calDAV report (11:08:43) pguenther: (at end) (11:08:44) Jim Whitehead: Thanks pguenther (11:08:59) hardie: We have agreed that CalDAV is the correct orthography, too, so score! (11:09:22) lisa: http://ietf.webdav.org:8080/bugzilla (11:09:43) pguenther: bugzilla is set up, report problems to Joe (11:10:06) pguenther: is the *canonical* repository for issues (11:10:22) pguenther: authors cannot close issues, only chairs (11:10:40) Jim Whitehead: how many people in the room in DC? (11:10:59) MatthewElvey entered the room. (11:11:06) pguenther: 8 + ADs + chairs (11:11:11) bdesruisseaux entered the room. (11:11:14) Jim Whitehead: thx (11:11:20) Julian Reschke: bugzilla: I think this needs to cc the mailing list (I know Lisa and Joe have been working on it; but it doesn't seem to work right now) (11:11:41) pguenther: right, Joe is still aiming towards that (11:11:43) Jim Whitehead: i received a few emails recently. think this integration is working (11:11:49) pguenther: sorry, slipped past my typing (11:12:11) pguenther: Julian sent in update on Bind (11:12:19) pguenther: WGLC on it soon (11:12:41) Julian Reschke: (no mails visibile on http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/) (11:12:55) Jim Whitehead: what is the plan for resolving open BIND issues and getting to WGLC? (11:12:55) pguenther: Lisa, as Julian: no open issues (11:13:21) pguenther: Lisa, as Lisa: some items found and put in bugzilla (11:13:45) codebear entered the room. (11:13:46) Julian Reschke: These issues IMHO are the same we already discussed on the mailing list. (11:14:00) Jim Whitehead: so do you think they're open or closed? (11:14:09) pguenther: moving on to Redirect: Julian: "Redirect to move forwards after BIND" (11:14:22) Julian Reschke: Discussion ended with consensus (as far as I can tell), if that's incorrect we'll need to restart it on the ML. (11:14:24) pguenther: Joe doesn't think there are any dependencies, just a matter of work (11:14:33) hildjj: Is that correct? (11:14:40) Julian Reschke: Yes. (11:14:59) Julian Reschke: There is one main issue left for which I'd appreciate feedback, which is... (11:15:03) Jim Whitehead: so, will there be one more I-D then WGLC, or are we going directly to WGLC? (11:15:07) lisa: I think redirect is closer to WGLC, personally (11:15:09) Jim Whitehead: on BIND that is (11:15:25) Julian Reschke: ...documented here: http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0180.html (11:15:26) lisa: redirect closer to WGLC than Bindings, to be clear (and both of those closer than RFC2518bis) (11:15:36) hildjj: Jim: WGLC on this issue, as soon as we get Bugzilla 100% (11:15:43) hildjj: issue/version (11:15:57) Jim Whitehead: bugzilla 100% means all issues reolved? (11:16:07) Julian Reschke: IMHO redirect indeed *has* open issues that need to be resolved before we can go to LC. (11:17:00) lisa: Yes Julian, that could be, but redirct has fewer issues and easier to resolve -- that's just my guess, based on the issues I'm aware of. (11:17:38) Jim Whitehead: wouldn't surprise me if that's the case -- redirect has fewer impacts on the rest of the DAV data model (11:18:00) lisa: that's right (11:18:07) Julian Reschke: I personally think that BIND is a litmus test about whether this WG is still functional or not. It has been in almost-last-call state for over 19 months, and it's on top of our prio list. Let's do not move other things in front of it. (11:19:14) pguenther: discussion: delete of redirection is the important case, which makes #1 choice preferable (11:19:27) pguenther: (or rather, the _really_ important case) (11:20:32) pguenther: Julian: Joe agrees with the sentiment of your concern over BIND and reordering the submission of the drafts (11:21:59) Julian Reschke: Meta: BIND is stable and has been implemented in various servers, while REDIRECT currently seems to be implemented by one single server (ours). Thus, the WG should keep BIND as #1 prio. (11:22:03) Jim Whitehead: i don't have a strong preference over which one is finished first -- obviously want to see both completed (11:22:05) pguenther: Ted (Hardie) to submit to bugzilla an issue over DELETE of a redirection not being explicitly described/warned about/pointed out (11:23:00) pguenther: moving on to QUOTA (11:23:07) pguenther: new draft submitted (11:23:15) lisa: Julian, it would be great to get a snapshot of the implementation status of BIND and REDIRECT, on the WG list. (11:23:25) pguenther: big change: removed 'authorable' property that was causing the most grief (11:23:44) pguenther: handful of nits (Thanks Julian!) (11:24:45) pguenther: suggestions to reorganize seem style issues and will be left to author (11:24:55) pguenther: WGLC real soon (11:25:02) pguenther: CalDAV notes (11:25:15) Jim Whitehead: I asked brian when a new draft would be created, haven't received a response. Would be good for him to receive some WG Chair direction on this (11:25:32) lisa: Brian just said, in the next week or so after he gets back from DC. (11:25:32) hildjj: brian says soon after he gets back. (11:25:35) lisa: heh (11:25:40) pguenther: calendaring roundtable was held (11:25:54) pguenther: added new resources and properties (11:26:21) pguenther: fourth draft adds new method 'add calender' (11:26:34) lisa: literally "MKCALENDAR" (11:27:09) pguenther: reached concensus over changes and are working on searches and some specific calendaring functions (11:27:21) lisa: It would be good to get broader feedback on our CalDAV ideas about property promotion... (11:27:59) lisa: it adds complexity (since we know we want to support access via iCalendar formatted bodies, anyway) but we're discussing whether the benefits outweigh that. (11:28:07) pguenther: property promotion as means to provide better searching including partial retrieval(?) (11:28:55) lisa: Yep -- better searching, partial retrieval, partial write. To change the DTSTART of an iCalendar body, the client must upload the whole body again. Unless we reflect the body's DTSTART value as a WebDAV property, in which case you could PROPPATCH only that property. (11:28:57) pguenther: discussion on promotion (11:29:32) Jim Whitehead: it certainly seems to me that calendar searching will be critical for making CalDAV interesting for Enterprise deployment. (11:29:53) lisa: Yes but SEARCH+basicsearch can't even meet the requirements. (11:30:19) Jim Whitehead: Doesn't surprise me -- will undoubtedly require a specific CaLDAV search vocabulary (11:30:30) pguenther: timezone as example of why a brute force renaming with separator isn't always good (11:30:32) lisa: yep -- expanding recurrances, time-range results, etc. (11:31:04) pguenther: use reports to do stuff beyond the capabilities of search (11:31:16) pguenther: what is being optimized for? (11:31:28) pguenther: smarts in server or client? (11:31:31) Jim Whitehead: Will also need a richer notion of principal than is provided by ACL spec -- will be tricky to stay away from an entire directory server capability (11:31:42) lisa: Why is that, Jim? (11:31:44) pguenther: shifted in calsch WG over time (11:32:03) pguenther: (where the smarts were expected to be, that is) (11:32:04) Jim Whitehead: True, REPORT would be very handy here. Trick is figuring out which REPORTs to support (11:32:45) Jim Whitehead: Principals in ACL spec don't have enough metadata (phone number, room number, etc.) -- no problem to add these, just need to have standard property lists (11:33:57) pguenther: searching and filtering take place on the server side, with knowledge of recurrence[sic] rules (11:34:02) lisa: We may only need one more principal property for CalDAV -- "calendar URL(s)" (11:34:13) lisa: the rest of the information can be properties on the calendar resources, I think (11:34:14) pguenther: servers _are_ being expected to understand the semantics of the objects (11:35:04) Jim Whitehead: For example, Oracle Calendar allows you to associate "organizations" to specific principals, you you can differentiate between the Nguyen in development and the Nguyen in accounting. (11:35:14) pguenther: that an assumption of several things, including promotion (but that may be doable with a shim), and recurrence (11:35:26) pguenther: the latter being critical to calendaring (11:35:49) lisa: Joe just realized he should add the webdav event stuff to the agenda... (11:38:08) pguenther: Oracle hoping to have basic IOP by mid January (11:38:58) Jim Whitehead: expand "IOP" please? (11:39:19) pguenther: sorry, have it in operation (11:39:32) pguenther: (short between ears and fingers) (11:39:36) Jim Whitehead: OK, what are they hoping to have in operation? CalDAV? (11:39:47) Jim Whitehead: Or have we moved on to events? (11:39:53) pguenther: yes, with searching (11:40:05) pguenther: "what meeting have I not responded to" etc (11:40:12) lisa: Joe mentioned the HTTP header registry, which Mark Nottingham is working on (11:40:24) lisa: IOP is "interoperability" (11:40:57) lisa: Some CalDAV features should interoperate in mid-Jan. (11:41:11) Jim Whitehead: Also, shameless plug: there will be an article on WebDAV in the Jan/Feb issue of IEEE Internet Computing. Will focus on the ACL specification (11:41:31) Jim Whitehead: How can you have interop when the spec isn't complete yet? (11:41:46) bdesruisseaux: The CalDAV protocol adapter of Oracle Calendar should provide support for GET, PUT, DELETE, PROPFIND and REPORTs to allow clients to create, modify, delete events as well as search for them (with reports). (11:41:54) Jim Whitehead: Or, put another way, what is the baseline for this? (11:42:12) Jim Whitehead: Is the CalDAV adapter going to be publically available? (11:42:27) pguenther: taking to list the details of having MKCAL indicate what it is putting up (11:42:33) Jim Whitehead: Who is the oracle contact for CalDAV? (11:42:56) lisa: Bernard DesRuisseaux (11:43:00) lisa: (in this room) (11:43:04) bdesruisseaux: We'll make the adapter available outside our firewall for CalDAV cllient initiative to work toward an IOP (11:43:08) lisa: (both physical and jabber room) (11:43:28) bdesruisseaux: Jim, I am the "dev" contact for CalDAV. (11:43:51) Jim Whitehead: Super! Thanks Bernard. We're an oracle calendar shop here at UCSC (11:44:16) bdesruisseaux: Good! (11:45:32) pguenther: Cyrus: no further immediate needs from CalDAV on WebDAV; if stuff comes up during implementation then it will be taken to the list (11:46:21) pguenther: Bernard: in future, stuff like QUOTA may become more important for CalDAV, to prevent DoS attacks in the direct case of QUOTA (11:46:30) Julian Reschke: If CalDAV in some way becomes an "official" WebDAV working group item, I'd like to see discussions to actually happen on the mailing list... (11:46:48) Jim Whitehead: there are separate mailing lists for caldav (11:46:58) Jim Whitehead: seems like it should be a separate WG in any case (11:47:07) Julian Reschke: Yes, but there seems to be a lot of out-of-band dicussion :-) (11:47:15) Jim Whitehead: :-) 11:47:29) Jim Whitehead: not clear caldav folks want to be an IETF WG (11:47:43) pguenther: for now, the CalDAV is expecting to stay as an individual submission (11:47:59) Julian Reschke: nothing wrong with that (11:48:30) lisa: There are certainly a lot of out-of-band discussions. Co-authors do that. (11:48:35) lisa: :-) (11:48:35) pguenther: Ted: HTTP SASL had a bunch of review comments (11:48:39) Jim Whitehead: agreed (11:49:12) lisa: I believe we're doing a good job of bringing the out-of-band discussions on CalDAV into the spec and publishing it frequently. (11:49:17) pguenther: comments are currently unreplied to and is stuck there until that happens, perhaps blocked on SASL WG (11:49:17) pguenther: ? (11:49:55) pguenther: Waiting on revision from Alexey based on review? (11:50:06) pguenther: Lisa: blocked on disagreeing on how HTTP is extensible (11:51:35) pguenther: Lisa: a use case for HTTP SASL would help it move forwards, perhaps (11:51:42) lisa: Also blocked on understanding why it's needed (11:52:02) pguenther: Cyrus/Ted: WebDAV pushing for HTTP SASL may serve (11:52:29) lisa: (Scott could probably come up with a proposed model, but he needs to be motivated by understanding "why SASL") (11:52:34) lisa: (Scott Lawrence, that is) (11:52:41) pguenther: Cyrus: webdav security considerations section, etc (11:52:55) pguenther: Moving on to events (11:53:23) pguenther: Joe: "being that we're XMPP people, this [events] is XMPP based" (11:53:40) Jim Whitehead: Seems like HTTP/DAV is doing fine without SASL. Would need to get buy-in from MSFT and Apache up front, otherwise is DOA. Without this buy-in, seems like it's not worth our time. (11:53:57) Jim Whitehead: Is there an events specification out? (11:54:06) Jim Whitehead: Or is this in the planning stages? (11:54:28) pguenther: http://www.jabber.org/~stpeter/ietf/dradft-saintandre-webdav-notify-00.html (11:54:35) Jim Whitehead: thx (11:55:01) pguenther: JEP #60 (publish/subscribe protocol on top of Jabber) (11:55:10) pguenther: JEP == Jabber Enhancement Proposal (11:55:20) pguenther: comes from Jabber Software Foundation (11:55:49) pguenther: notify spec says how to use that spec to put on top of it "this resouce was modified", perhaps also "here what was changed" (11:55:54) lisa: I've proposed we follow up HTTP SASL questions on the HTTP list and see if we can get broader input there... Jim do you still subscribe to that list? Can you point out the buy-in problem? (11:56:09) pguenther: optional new property giving place to go for changes (11:56:17) Jim Whitehead: url is actually: http://www.jabber.org/~stpeter/ietf/draft-hildebrand-webdav-notify-00.html (11:56:38) Jim Whitehead: I've never been on the SASL list, would be willing to point out buy-in problem. (11:56:43) lisa: thanks Jim! (11:57:13) pguenther: (this was in revenge, stpeter on joe) (11:57:17) lisa: There's not a specific SASL list... so I suggested discussing HTTP SASL on ietf-http-wg@w3.org (11:57:34) pguenther: Joe: does this ID deserve a home in WG (11:57:35) lisa: I mean, there probably is a SASL list, but our problem is not the SASL part of it. (11:57:37) Jim Whitehead: ah, ok. yeah, that list is really quiet (11:57:45) pguenther: Ted: isn't this also in atompub? (11:57:45) Julian Reschke: yes, there is: http://www.imc.org/ietf-sasl/ (11:57:53) pguenther: Joe: that's a different draft (11:57:57) lisa: Our HTTP/SASL problem is how to extend HTTP in a HTTP-like way, that works with intermediaries, to support SASL -- and why to do so. (11:58:03) Jim Whitehead: I can also contact authors directly. (11:58:25) pguenther: Cyrus: security? how to do authentication? (11:58:27) lisa: I've just asked Alexey Melnikov to try to kick off discussion on mailto:ietf-http-wg@w3.org. (11:58:38) pguenther: Joe: if you have SASL it's easy, and XMPP has SASL (11:58:38) Jim Whitehead: OK, why do we want SASL? I don't hear lots of calls for replacing current SSL layer, and the CONNECT method isn't getting lots of adoption AFAIK (12:00:06) pguenther: Joe: they have a server that has separate "who's allowed to publish" and "who's allowed to subscribe" (12:01:38) pguenther: Joe: similarity to XMPP is nice; gives a dual XMPP/WedDAV client ability to use the same creds/stuff to authentice to both (12:02:04) pguenther: Cyrus: similar to URLAUTH? (12:02:11) pguenther: (from LEMONADE) (12:02:34) pguenther: so called "pawn ticket" model: whoever has the token can fetch resource (12:02:37) Jim Whitehead: thx -- so the issue gets more important as XMPP gains in adoption, and XMPP/DAV synergies become more useful (12:03:08) pguenther: Lisa: old draft of this used by Lycos (12:03:15) lisa: Not Lycos, Xythos :-) (12:03:41) ***pguenther curses at the phenomes used by English (12:03:57) pguenther: Jim: right (12:04:51) lisa: Philip are you worried about Phonemes or Pheromones? (12:05:30) ***pguenther curses at English in general (12:05:36) pguenther: should never made it out of draft (12:05:46) pguenther: Moving on to PATCH (12:06:17) pguenther: Lisa: unable to register mime-type GDIF due to issues with IPR (12:06:35) pguenther: make VCDIF the required form? (12:06:56) pguenther: but it can only be used in HTTP/1.1 according to its IPR statement! (12:07:08) Julian Reschke left the room (Replaced by new connection). (12:07:08) Julian Reschke entered the room. (12:07:09) Julian Reschke left the room. (12:07:17) Julian Reschke entered the room. (12:07:18) pguenther: there is not another diff format out there to use (12:07:22) Jim Whitehead: don't understand IPR issue. MIME type registration doesn't involve any exposure of IPR, as I recall (12:07:35) pguenther: don't require diff format to be supported? (12:07:48) Jim Whitehead: For example, MSFT still has complete control over .doc format, but still has MIME type for it (12:08:00) Julian Reschke: I think we'll need at least one simple diff format that all severs and clients will support. (12:08:11) pguenther: IANA won't register an application/* type without resolution of IPR issues (12:08:34) Julian Reschke: REQUIRING support for a format with unclear IPR is problematic. (12:08:48) Jim Whitehead: Agreed (12:08:52) lisa: Yes, agreed. (12:08:55) lisa: And then... ? (12:09:05) Jim Whitehead: Subversion uses vdelta, but that also has a patent on it (12:10:09) pguenther: Ted: talk to Jeff Mogul? (12:10:17) pguenther: Lisa: yes, he said use VCDIFF (12:10:58) pguenther: suggestion to ask Jeff to lean on people to update/extend IPR grant to apply to more uses including WebDAV (12:11:00) Julian Reschke: I looked at VCDIFF a few weeks ago and it seems to be way to complicated as a required base format. (12:11:03) Jim Whitehead: Seems like we have three choices: (1) explore where a common delta has RAND licensing (or owner is willing to commit to RAND) (2) develop a new diff format that isn't patented (hard, lots of IP in this space) (3) use a really old delta format (like the Unix diff used in SCCS, or possibly even the diffs used in RCS (12:11:46) Jim Whitehead: There is also the XML diff format developed by Vitali and Durand, called VTML (12:12:01) Julian Reschke: Need to consider different use cases: text patch (as in diff/patch) and binary patch (like when writing back only parts of a binary resource) (12:12:37) Julian Reschke: (the latter likely to be useful for clients that map WebDAV to file I/O) (12:12:54) Jim Whitehead: VTML URL is http://www.cs.unibo.it/~fabio/bio/papers/1999/SCM99/SCM9.pdf (12:13:02) lisa: There's also the XML diff format developed by Adrian Mouat (12:13:07) Jim Whitehead: Agreed VTML would be problematic for binary diffs (12:13:12) lisa: yup (12:13:48) pguenther: Joe: regarding diff comments: "Can of worms; move on for now" (12:14:11) pguenther: Lisa: where to put content-type of patch in HTTP? (12:14:32) Jim Whitehead: Seems to me we don't really need a compressed diff format. Something that says insert n octets starting at octet y, using encoding z would do the trick (12:14:50) Julian Reschke: ...into the content-type header, as defined in RFC2616... (12:14:54) hildjj: Jim: that's gdiff, no? (12:14:56) pguenther: long history of HTTP Content-Type and "instance-Manipulation" headers (12:15:23) Jim Whitehead: Don't know gdiff (12:15:39) Julian Reschke: Yep, that's basically gdiff. (12:16:04) pguenther: (i.e., can the content-type header be of the underlying object, even when the actual body of the request is really instruction to modify it) (12:16:29) Julian Reschke: (http://www.w3.org/TR/NOTE-gdiff-19970901) (12:16:34) pguenther: Joe: stuff is clearly still open; PATCH is not a working group item (12:16:42) Julian Reschke left the room (Replaced by new connection). (12:16:43) Julian Reschke entered the room. (12:16:43) Julian Reschke left the room. (12:16:46) Jim Whitehead: Just looked at gdiff spec. Would be easy to design something similar, but still markedly different (12:16:47) Julian Reschke entered the room. (12:16:52) Jim Whitehead: Does gdiff have IPR issues? (12:17:04) lisa: Gdiff is not known not to have IPR issues. (12:17:24) lisa: I submitted an IANA registration for application/gdiff and it was rejected because IPR issues were not clear. (12:17:25) pguenther: Bernard: calendaring change format could be done using diff format, so would be nice there too (12:17:35) lisa: Joe (12:17:41) lisa: Joe is declaring we're finished... (12:17:47) hildjj: anything else before we're done? (12:17:48) lisa: unless there are any last-minute issues (12:18:11) pguenther: gavel has fallen (12:18:18) hildjj: < (12:18:19) bdesruisseaux left the room. (12:18:22) Julian Reschke: I'd like us as WG to agree that we concentrate on the topics that are on top of our charter. (12:18:37) hildjj: Julian: yes. BIND first. (12:19:04) Jim Whitehead: OK (12:19:16) hildjj left the room. (12:19:16) Julian Reschke: People who do have open issues with the latest draft, *please* post them to the ML for dicussion. (12:19:50) Jim Whitehead: OK (12:25:41) hardie left the room (Disconnected). (12:25:57) codebear left the room. (12:26:20) Julian Reschke left the room (Disconnected). < -- Joe Hildebrand Denver, CO, USA --Apple-Mail-15--153567437-- From w3c-dist-auth-request@w3.org Fri Dec 10 14:46:28 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10236 for ; Fri, 10 Dec 2004 14:46:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ccqi9-0006f4-NM for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 19:45:53 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ccqi9-0006eQ-Fp for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 19:45:53 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1Ccqi9-00073k-5s for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 19:45:53 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBAJjaaa013776 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 10 Dec 2004 11:45:44 -0800 In-Reply-To: <41B9EAEA.8030007@gmx.de> References: <200412090012.iB90CZKX014846@cats-mx4.ucsc.edu> <41B9EAEA.8030007@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0BEA366E-4AE4-11D9-AC43-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: ejw@cs.ucsc.edu, "'webdav'" From: Lisa Dusseault Date: Fri, 10 Dec 2004 11:45:29 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/0BEA366E-4AE4-11D9-AC43-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9184 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 19:45:53 +0000 Content-Transfer-Encoding: 7bit What about a live property called "nextPhoto" on a WebDAV collection of photos? Then it's trivial to do a "slideshow" for that collection, going from one photo to the next. You can support one photo that appears in multiple slideshows through bindings, and the value for "nextPhoto" depends on which slide show the client is looking at, which is clearly detectable from the URL. This kind of thing could be useful for other applications as well. It could even work with PROPPATCH, because the server knows to treat this as a "per-binding" property and change only the value that applies for this binding. I can even imagine a generic way of the client telling the server to "create me this new dead property as a per-binding property" so that the client can provide a new value per binding. Lisa On Dec 10, 2004, at 10:28 AM, Julian Reschke wrote: > > Jim Whitehead wrote: >> ... > > >> There's nothing in 2518 that implies a live property's computation >> depends >> only on the state of the resource. It would be prefectly valid to >> have a >> live property that returned a random number. > > : > > "Properties are pieces of data that describe the state of a resource. > Properties are data about data." > > Also note that aforementioned live property wouldn't *vary* by > binding; it would just be random. What I'm looking for is a use-case > where properties varying by *binding* really make sense. So far, I'm > not aware of any case where this wouldn't be better modelled as a > property on the collection holding the binding. > >> I'm not too worried about encouraging binding-specific properties, as >> I >> believe implementors would be able to see the potential usability >> drawbacks >> of such properties. > > I tend to disagree here (judging from previous reactions) :-) > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Fri Dec 10 15:07:37 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12513 for ; Fri, 10 Dec 2004 15:07:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ccr2L-0003wZ-RG for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 20:06:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Ccr2L-0003w5-IJ for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 20:06:45 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1Ccr2D-0000cu-Te for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 20:06:38 +0000 Received: (qmail 19970 invoked by uid 65534); 10 Dec 2004 20:06:08 -0000 Received: from pD9FF04A5.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.4.165) by mail.gmx.net (mp005) with SMTP; 10 Dec 2004 21:06:08 +0100 X-Authenticated: #1915285 Message-ID: <41BA019E.5080209@gmx.de> Date: Fri, 10 Dec 2004 21:05:50 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: ejw@cs.ucsc.edu, "'webdav'" References: <200412090012.iB90CZKX014846@cats-mx4.ucsc.edu> <41B9EAEA.8030007@gmx.de> <0BEA366E-4AE4-11D9-AC43-000A95B2BB72@osafoundation.org> In-Reply-To: <0BEA366E-4AE4-11D9-AC43-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41BA019E.5080209@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9185 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 20:06:45 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > What about a live property called "nextPhoto" on a WebDAV collection of > photos? Then it's trivial to do a "slideshow" for that collection, > going from one photo to the next. You can support one photo that > appears in multiple slideshows through bindings, and the value for > "nextPhoto" depends on which slide show the client is looking at, which > is clearly detectable from the URL. Either use Ordered Collections (RFC3648), add a multi-valued property on the collection container, or expose the information as pair (parent-collection, next-binding) on the resource. > This kind of thing could be useful for other applications as well. It > could even work with PROPPATCH, because the server knows to treat this > as a "per-binding" property and change only the value that applies for > this binding. So where do you store it? Either on the resource itself (in which case you need to maintain that property for each parent collection, so you could simply expose that information as well), or on the collection. > I can even imagine a generic way of the client telling the server to > "create me this new dead property as a per-binding property" so that the > client can provide a new value per binding. I can imagine a lot of things as well. The question is: do we really need that and how does fit into the model that we're using for WebDAV? BTW: you seem to be changing positions frequently :-) May I remind you that you asked that the BIND spec mandates that properties MUST NOT vary across bindings? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 10 15:10:53 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13081 for ; Fri, 10 Dec 2004 15:10:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ccr5i-000580-V1 for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 20:10:14 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ccr5i-00057V-Fb for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 20:10:14 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Ccr5i-0005qw-18 for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 20:10:14 +0000 Received: (qmail 3343 invoked by uid 65534); 10 Dec 2004 20:09:41 -0000 Received: from pD9FF04A5.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.4.165) by mail.gmx.net (mp010) with SMTP; 10 Dec 2004 21:09:41 +0100 X-Authenticated: #1915285 Message-ID: <41BA0275.2090302@gmx.de> Date: Fri, 10 Dec 2004 21:09:25 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: ejw@cs.ucsc.edu, "'webdav'" References: <200412090012.iB90CZKX014846@cats-mx4.ucsc.edu> <41B9EAEA.8030007@gmx.de> <0BEA366E-4AE4-11D9-AC43-000A95B2BB72@osafoundation.org> In-Reply-To: <0BEA366E-4AE4-11D9-AC43-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41BA0275.2090302@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9186 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 20:10:14 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > What about a live property called "nextPhoto" on a WebDAV collection of > photos? Then it's trivial to do a "slideshow" for that collection, > going from one photo to the next. You can support one photo that > appears in multiple slideshows through bindings, and the value for > "nextPhoto" depends on which slide show the client is looking at, which > is clearly detectable from the URL. > > This kind of thing could be useful for other applications as well. It > could even work with PROPPATCH, because the server knows to treat this > as a "per-binding" property and change only the value that applies for > this binding. > > I can even imagine a generic way of the client telling the server to > "create me this new dead property as a per-binding property" so that the > client can provide a new value per binding. > > Lisa Forgot to mention...: what you describe here (to me) clearly is a case of where the information you want to expose is part of the state of the slide show, not of an individual picture. So it seems to be quite obvious to model the slide show as WebDAV collection, and to maintain ordering and other defaults (display time, effects, whatever) as state of that collection. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 10 15:38:47 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15983 for ; Fri, 10 Dec 2004 15:38:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcrW6-0005aH-Nd for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 20:37:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CcrW3-0005Z1-O1 for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 20:37:27 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by lisa.w3.org with esmtp (Exim 4.34) id 1CcrVw-0001NJ-4i for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 20:37:20 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15877; Fri, 10 Dec 2004 15:37:24 -0500 (EST) Message-Id: <200412102037.PAA15877@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Date: Fri, 10 Dec 2004 15:37:24 -0500 Received-SPF: none (lisa.w3.org: domain of dinaras@cnri.reston.va.us does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: I-D ACTION:draft-ietf-webdav-bind-09.txt X-Archived-At: http://www.w3.org/mid/200412102037.PAA15877@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9187 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 20:37:30 +0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) Author(s) : G. Clemm, et al. Filename : draft-ietf-webdav-bind-09.txt Pages : 42 Date : 2004-12-10 This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-bind-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-bind-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-10155801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-bind-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-bind-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-10155801.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Fri Dec 10 15:39:11 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16006 for ; Fri, 10 Dec 2004 15:39:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CcrXD-000615-Sw for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 20:38:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CcrXC-00060N-P3 for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 20:38:38 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CcrX5-0001l4-46 for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 20:38:31 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBAKcVaa015509 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 10 Dec 2004 12:38:33 -0800 In-Reply-To: <41BA019E.5080209@gmx.de> References: <200412090012.iB90CZKX014846@cats-mx4.ucsc.edu> <41B9EAEA.8030007@gmx.de> <0BEA366E-4AE4-11D9-AC43-000A95B2BB72@osafoundation.org> <41BA019E.5080209@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <70B3C698-4AEB-11D9-AC43-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: ejw@cs.ucsc.edu, "'webdav'" From: Lisa Dusseault Date: Fri, 10 Dec 2004 12:38:25 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/70B3C698-4AEB-11D9-AC43-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9188 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 20:38:39 +0000 Content-Transfer-Encoding: 7bit > >> This kind of thing could be useful for other applications as well. >> It could even work with PROPPATCH, because the server knows to treat >> this as a "per-binding" property and change only the value that >> applies for this binding. > > So where do you store it? Either on the resource itself (in which case > you need to maintain that property for each parent collection, so you > could simply expose that information as well), or on the collection. WebDAV servers *store* things any way they like. E.g. a new table in the backend database called "PER_BINDING_PROPS" with column headers for binding, property name and value. Who cares how they store it -- that's what gives the implementors flexibility. WebDAV's model and marshalling are what we're talking about. > > BTW: you seem to be changing positions frequently :-) May I remind you > that you asked that the BIND spec mandates that properties MUST NOT > vary across bindings? > As it happens, I am not changing positions on this issue (although I reserve my right to change my mind if I'm convinced by an argument or think of new cases). I have held this position for a year or more now and will try to state it again another way: That servers should be allowed to vary properties per binding and IF that's the consensus... then the specification should warn clients that "clients MUST be prepared for properties that vary per binding" ELSE IF the consensus (despite my opinion) is that properties can't vary per binding then the specification should say that properties MUST NOT vary across bindings. Lisa From w3c-dist-auth-request@w3.org Fri Dec 10 15:52:07 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18771 for ; Fri, 10 Dec 2004 15:52:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ccric-0002m7-DV for w3c-dist-auth-dist@listhub.w3.org; Fri, 10 Dec 2004 20:50:26 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ccrib-0002lb-RK for w3c-dist-auth@listhub.w3.org; Fri, 10 Dec 2004 20:50:25 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1Ccrib-0003di-HS for w3c-dist-auth@w3.org; Fri, 10 Dec 2004 20:50:25 +0000 Received: (qmail 29148 invoked by uid 65534); 10 Dec 2004 20:49:53 -0000 Received: from pD9FF04A5.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.4.165) by mail.gmx.net (mp015) with SMTP; 10 Dec 2004 21:49:53 +0100 X-Authenticated: #1915285 Message-ID: <41BA0BE1.4010805@gmx.de> Date: Fri, 10 Dec 2004 21:49:37 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: ejw@cs.ucsc.edu, "'webdav'" References: <200412090012.iB90CZKX014846@cats-mx4.ucsc.edu> <41B9EAEA.8030007@gmx.de> <0BEA366E-4AE4-11D9-AC43-000A95B2BB72@osafoundation.org> <41BA019E.5080209@gmx.de> <70B3C698-4AEB-11D9-AC43-000A95B2BB72@osafoundation.org> In-Reply-To: <70B3C698-4AEB-11D9-AC43-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41BA0BE1.4010805@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9189 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 10 Dec 2004 20:50:26 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >>> This kind of thing could be useful for other applications as well. >>> It could even work with PROPPATCH, because the server knows to treat >>> this as a "per-binding" property and change only the value that >>> applies for this binding. >> >> >> So where do you store it? Either on the resource itself (in which case >> you need to maintain that property for each parent collection, so you >> could simply expose that information as well), or on the collection. > > > WebDAV servers *store* things any way they like. E.g. a new table in > the backend database called "PER_BINDING_PROPS" with column headers for > binding, property name and value. Who cares how they store it -- that's > what gives the implementors flexibility. WebDAV's model and marshalling > are what we're talking about. Yes, and WebDAV's (that is, HTTP's) model involves resources and URIs. URIs are used to address resources, and content and properties represent the state of the *resource*, no the URI. If you want things to vary based on the binding, store them with the binding, and in WebDAV's model, that's part of the state of the parent collection. It's ok to do this, but if you do things will stay much simpler if you work with that model. For instance, is PROPPATCHing "the next picture" modifying the state of the picture, or that of the slide show? If it's part of the picture, I'll need write permissions to the picture resource, right? Why would I need that if the only thing I do is changing the ordering in a container object (the slide show)? >> BTW: you seem to be changing positions frequently :-) May I remind you >> that you asked that the BIND spec mandates that properties MUST NOT >> vary across bindings? >> > As it happens, I am not changing positions on this issue (although I > reserve my right to change my mind if I'm convinced by an argument or > think of new cases). I have held this position for a year or more now > and will try to state it again another way: > > That servers should be allowed to vary properties per binding and IF > that's the consensus... > then the specification should warn clients that "clients MUST be > prepared for properties that vary per binding" > ELSE IF the consensus (despite my opinion) is that properties can't vary > per binding > then the specification should say that properties MUST NOT vary > across bindings. As far as I can tell, there is no consensus for either of these. RFC2518 says that properties "describe the state of a resource". People seem to come to different conclusions about what this means, but if this is the case, it should be fixed in RFC2518, not in BIND. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 13 15:19:31 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14918 for ; Mon, 13 Dec 2004 15:19:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CdwcO-0008Vr-30 for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Dec 2004 20:16:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CdwcL-0008Ux-5R for w3c-dist-auth@listhub.w3.org; Mon, 13 Dec 2004 20:16:25 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by lisa.w3.org with esmtp (Exim 4.34) id 1CdwcD-00062K-9W for w3c-dist-auth@w3.org; Mon, 13 Dec 2004 20:16:17 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iBDKFnUa007048 for ; Mon, 13 Dec 2004 12:15:53 -0800 (PST) Message-Id: <200412132015.iBDKFnUa007048@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Mon, 13 Dec 2004 12:15:40 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <41B9CB79.5060408@gmx.de> thread-index: AcTe06RZtkBW3IMhQJ20zA9060dNWQCeystA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: REBIND and lock token submission example X-Archived-At: http://www.w3.org/mid/200412132015.iBDKFnUa007048@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9190 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Dec 2004 20:16:28 +0000 Content-Transfer-Encoding: 7bit Julian writes: > REBIND /CollW/CollX HTTP/1.1 > If: () > Content-Type: application/xml > > > CollA > /CollW/CollY/CollZ > I've double-checked this, and believe it to be correct. > Do we have consensus to add this example at all? My recollection is that Lisa was in favor, and Geoff was neutral. Given that we're talking about adding an example, and not additional requirements, my recommendation is to consider this sufficient rough consensus, and add the example. > If so, would > it make sense to *replace* the REBIND example we already have > in section 6.1 > ( st.html#rfc.section.6.1>)? I'd say no -- having both examples makes sense, since the first one is relatively simple, and the second one is more complex. I'd also recommend adding text to the example description along the lines of "The binding between CollZ and C1 creates a loop in the containment hierarchy. Servers are not required to support such loops, though the server in this example does." The reason for this is to ensure that implementors aren't accidentally left with the impression they must implement loop-causing bindings. - Jim From w3c-dist-auth-request@w3.org Mon Dec 13 15:44:56 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16897 for ; Mon, 13 Dec 2004 15:44:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cdx3F-0008Ly-6n for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Dec 2004 20:44:13 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cdx3C-0008Kb-Gl for w3c-dist-auth@listhub.w3.org; Mon, 13 Dec 2004 20:44:10 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by bart.w3.org with esmtp (Exim 4.34) id 1Cdx3C-0005Pl-9Z for w3c-dist-auth@w3.org; Mon, 13 Dec 2004 20:44:10 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iBDKhCY4012359 for ; Mon, 13 Dec 2004 12:43:15 -0800 (PST) Message-Id: <200412132043.iBDKhCY4012359@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'webdav'" Date: Mon, 13 Dec 2004 12:43:03 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <41BA0BE1.4010805@gmx.de> thread-index: AcTe+grx+vbt1T8DRuiDwwJL2mb7iwCWQadA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/200412132043.iBDKhCY4012359@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9191 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Dec 2004 20:44:13 +0000 Content-Transfer-Encoding: 7bit Let me suggest the following language. I think we all agree this is a minimum level statement on the issue -- where we differ is in how to go beyond this level (Julian wants to change the SHOULD to a MUST , while I'd like to add an additional MAY). Proposed language: Note that, consistent with [RFC2518], the value of a dead property is independent of the number of bindings to its host resource or of the path submitted to PROPFIND. Similarly consistent with [RFC2518], the value of a live property SHOULD be independent of the number of bindings to its host resource, and of the path submitted to PROPFIND. The reason for the two almost-identical sentences is to address Julian's desire to not include spec. language that's obvious from a careful reading of 2518. I personally prefer the following, more compact construction: Consistent with [RFC2518] the value of a dead property MUST be, and the value of a live property SHOULD be, independent of the number of bindings to its host resource or of the path submitted to PROPFIND. - Jim From w3c-dist-auth-request@w3.org Mon Dec 13 15:49:00 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17208 for ; Mon, 13 Dec 2004 15:49:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cdx7C-0001mq-AX for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Dec 2004 20:48:18 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cdx7B-0001mG-Sk for w3c-dist-auth@listhub.w3.org; Mon, 13 Dec 2004 20:48:17 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by bart.w3.org with esmtp (Exim 4.34) id 1Cdx7B-00083d-JZ for w3c-dist-auth@w3.org; Mon, 13 Dec 2004 20:48:17 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iBDKkufX013126 for ; Mon, 13 Dec 2004 12:46:59 -0800 (PST) Message-Id: <200412132046.iBDKkufX013126@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Mon, 13 Dec 2004 12:46:47 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <41B9D42F.7040609@gmx.de> thread-index: AcTe2LaJXyPxJNmsS02J8koj0mh+3ACfB8xw X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: status of BIND issue 2.6_when_do_ids_change X-Archived-At: http://www.w3.org/mid/200412132046.iBDKkufX013126@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9192 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Dec 2004 20:48:18 +0000 Content-Transfer-Encoding: 7bit This issue can be closed. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > Sent: Friday, December 10, 2004 8:52 AM > To: 'WebDAV (WebDAV WG)' > Subject: status of BIND issue 2.6_when_do_ids_change > > > Hi, > > here's a leftover (I made a change, but I didn't get back any > feedback about whether I can close the issue): > > ml#rfc.issue. > 2.6_when_do_ids_change> > > Jim, you raised the issue, could you please advise how to > proceed with it? > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Mon Dec 13 17:09:02 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01701 for ; Mon, 13 Dec 2004 17:09:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CdyLi-0006q3-Kc for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Dec 2004 22:07:22 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CdyLg-0006pV-Bc for w3c-dist-auth@listhub.w3.org; Mon, 13 Dec 2004 22:07:20 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CdyLg-0001wq-58 for w3c-dist-auth@w3.org; Mon, 13 Dec 2004 22:07:20 +0000 Received: (qmail invoked by alias); 13 Dec 2004 22:06:48 -0000 Received: from p54856D1E.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.109.30) by mail.gmx.net (mp024) with SMTP; 13 Dec 2004 23:06:48 +0100 X-Authenticated: #1915285 Message-ID: <41BE1272.20207@gmx.de> Date: Mon, 13 Dec 2004 23:06:42 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412132046.iBDKkufX013126@cats-mx3.ucsc.edu> In-Reply-To: <200412132046.iBDKkufX013126@cats-mx3.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: status of BIND issue 2.6_when_do_ids_change X-Archived-At: http://www.w3.org/mid/41BE1272.20207@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9193 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Dec 2004 22:07:22 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > This issue can be closed. Thanks. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 13 17:10:30 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01862 for ; Mon, 13 Dec 2004 17:10:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CdyOB-0007Ys-Gi for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Dec 2004 22:09:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CdyOB-0007YJ-2R for w3c-dist-auth@listhub.w3.org; Mon, 13 Dec 2004 22:09:55 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CdyO3-000131-3x for w3c-dist-auth@w3.org; Mon, 13 Dec 2004 22:09:47 +0000 Received: (qmail invoked by alias); 13 Dec 2004 22:09:22 -0000 Received: from p54856D1E.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.109.30) by mail.gmx.net (mp024) with SMTP; 13 Dec 2004 23:09:22 +0100 X-Authenticated: #1915285 Message-ID: <41BE130D.4050300@gmx.de> Date: Mon, 13 Dec 2004 23:09:17 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'webdav'" References: <200412132043.iBDKhCY4012359@cats-mx3.ucsc.edu> In-Reply-To: <200412132043.iBDKhCY4012359@cats-mx3.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41BE130D.4050300@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9194 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Dec 2004 22:09:55 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Let me suggest the following language. I think we all agree this is a > minimum level statement on the issue -- where we differ is in how to go > beyond this level (Julian wants to change the SHOULD to a MUST , while I'd > like to add an additional MAY). > > Proposed language: > > Note that, consistent with [RFC2518], the value of a dead property is > independent of the number of bindings to its host resource or of the > path submitted to PROPFIND. Similarly consistent with [RFC2518], the > value of a live property SHOULD be independent of the number of > bindings to its host resource, and of the path submitted to PROPFIND. > > The reason for the two almost-identical sentences is to address Julian's > desire to not include spec. language that's obvious from a careful reading > of 2518. I personally prefer the following, more compact construction: > > Consistent with [RFC2518] the value of a dead property MUST be, and the > value of a live property SHOULD be, independent of the number of bindings to > its host resource or of the path submitted to PROPFIND. I personally would prefer to stay silent about the topic, but if everybody else is agreeing, I'll be happy to add one of these (preferrably the latter, shorter one). Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 13 17:36:53 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03606 for ; Mon, 13 Dec 2004 17:36:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CdynX-0006eo-8e for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Dec 2004 22:36:07 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CdynW-0006eD-QH for w3c-dist-auth@listhub.w3.org; Mon, 13 Dec 2004 22:36:06 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CdynW-0002DZ-FZ for w3c-dist-auth@w3.org; Mon, 13 Dec 2004 22:36:06 +0000 Received: (qmail invoked by alias); 13 Dec 2004 22:35:34 -0000 Received: from p54856D1E.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.109.30) by mail.gmx.net (mp022) with SMTP; 13 Dec 2004 23:35:34 +0100 X-Authenticated: #1915285 Message-ID: <41BE192F.50503@gmx.de> Date: Mon, 13 Dec 2004 23:35:27 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200412132015.iBDKFnUa007048@cats-mx3.ucsc.edu> In-Reply-To: <200412132015.iBDKFnUa007048@cats-mx3.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: REBIND and lock token submission example X-Archived-At: http://www.w3.org/mid/41BE192F.50503@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9195 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Dec 2004 22:36:07 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > My recollection is that Lisa was in favor, and Geoff was neutral. Given that > we're talking about adding an example, and not additional requirements, my > recommendation is to consider this sufficient rough consensus, and add the > example. > > >>If so, would >>it make sense to *replace* the REBIND example we already have >>in section 6.1 >>(>st.html#rfc.section.6.1>)? > > > I'd say no -- having both examples makes sense, since the first one is > relatively simple, and the second one is more complex. > > I'd also recommend adding text to the example description along the lines of > "The binding between CollZ and C1 creates a loop in the containment > hierarchy. Servers are not required to support such loops, though the server > in this example does." Can we rephrase this a bit? It's never one specific binding that creates the loop.... > The reason for this is to ensure that implementors aren't accidentally left > with the impression they must implement loop-causing bindings. OK, proposed example text in . Do we need to say something about the "If" header? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 13 20:00:44 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14541 for ; Mon, 13 Dec 2004 20:00:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ce11n-0002QR-3p for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Dec 2004 00:58:59 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ce11k-0002Pr-S5 for w3c-dist-auth@listhub.w3.org; Tue, 14 Dec 2004 00:58:56 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by bart.w3.org with esmtp (Exim 4.34) id 1Ce11k-0003GB-JI for w3c-dist-auth@w3.org; Tue, 14 Dec 2004 00:58:56 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iBE0vvMZ002462 for ; Mon, 13 Dec 2004 16:58:01 -0800 (PST) Message-Id: <200412140058.iBE0vvMZ002462@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV \(WebDAV WG\)'" Date: Mon, 13 Dec 2004 16:57:45 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <41BE192F.50503@gmx.de> thread-index: AcThZCzuZABl0kIyRhSs0/98n74u8QAExLqg X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: REBIND and lock token submission example X-Archived-At: http://www.w3.org/mid/200412140058.iBE0vvMZ002462@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9196 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 14 Dec 2004 00:58:59 +0000 Content-Transfer-Encoding: 7bit > Can we rephrase this a bit? It's never one specific binding > that creates the loop.... Sure. How about: "This example shows a collection hierarchy with an internal cycle. Servers are not required to support cycles in the containment hierarchy, though the server in this example does." > Do we need to say something about the "If" header? Seems like a good idea. How about adding, at the end of the sentence ending in "... to the collection C2.": An If header is present in the request to submit the lock token for the lock on the source and destination resources. In this case, the source and the destination are both covered by the same lock, and hence only one lock token needs to be supplied. - Jim From w3c-dist-auth-request@w3.org Tue Dec 14 00:15:29 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03135 for ; Tue, 14 Dec 2004 00:15:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ce50L-0004TQ-Nq for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Dec 2004 05:13:45 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ce50J-0004S1-Ed; Tue, 14 Dec 2004 05:13:43 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by bart.w3.org with esmtp (Exim 4.34) id 1Ce50J-00076g-9D; Tue, 14 Dec 2004 05:13:43 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iBE5DB8F027006; Tue, 14 Dec 2004 00:13:11 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iBE5DBMa215708; Tue, 14 Dec 2004 00:13:11 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iBE5DB6Y014152; Tue, 14 Dec 2004 00:13:11 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iBE5DBmU014147; Tue, 14 Dec 2004 00:13:11 -0500 In-Reply-To: <41BE130D.4050300@gmx.de> To: Julian Reschke Cc: ejw@cs.ucsc.edu, "'webdav'" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 14 Dec 2004 00:13:09 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/14/2004 00:13:10, Serialize complete at 12/14/2004 00:13:10 Content-Type: multipart/alternative; boundary="=_alternative 001CAACB85256F6A_=" Received-SPF: none (bart.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/OFB1910C03.E6C24FAE-ON85256F6A.001C8743-85256F6A.001CAACC@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9197 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 14 Dec 2004 05:13:45 +0000 This is a multipart message in MIME format. --=_alternative 001CAACB85256F6A_= Content-Type: text/plain; charset="US-ASCII" I also would prefer to remain silent, but I can live with this text (I prefer the shorter version). Cheers, Geoff Julian wrote on 12/13/2004 05:09:17 PM: > > Jim Whitehead wrote: > > Let me suggest the following language. I think we all agree this is a > > minimum level statement on the issue -- where we differ is in how to go > > beyond this level (Julian wants to change the SHOULD to a MUST , while I'd > > like to add an additional MAY). > > > > Proposed language: > > > > Note that, consistent with [RFC2518], the value of a dead property is > > independent of the number of bindings to its host resource or of the > > path submitted to PROPFIND. Similarly consistent with [RFC2518], the > > value of a live property SHOULD be independent of the number of > > bindings to its host resource, and of the path submitted to PROPFIND. > > > > The reason for the two almost-identical sentences is to address Julian's > > desire to not include spec. language that's obvious from a careful reading > > of 2518. I personally prefer the following, more compact construction: > > > > Consistent with [RFC2518] the value of a dead property MUST be, and the > > value of a live property SHOULD be, independent of the number of bindings to > > its host resource or of the path submitted to PROPFIND. > > I personally would prefer to stay silent about the topic, but if > everybody else is agreeing, I'll be happy to add one of these > (preferrably the latter, shorter one). > > Feedback appreciated, > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 001CAACB85256F6A_= Content-Type: text/html; charset="US-ASCII"
I also would prefer to remain silent, but I can live with this text
(I prefer the shorter version).

Cheers,
Geoff

Julian wrote on 12/13/2004 05:09:17 PM:

>
> Jim Whitehead wrote:
> > Let me suggest the following language. I think we all agree this is a
> > minimum level statement on the issue -- where we differ is in how to go
> > beyond this level (Julian wants to change the SHOULD to a MUST , while I'd
> > like to add an additional MAY).
> >
> > Proposed language:
> >
> > Note that, consistent with [RFC2518], the value of a dead property is
> > independent of the number of bindings to its host resource or of the
> > path submitted to PROPFIND. Similarly consistent with [RFC2518], the
> > value of a live property SHOULD be independent of the number of
> > bindings to its host resource, and of the path submitted to PROPFIND.
> >
> > The reason for the two almost-identical sentences is to address Julian's
> > desire to not include spec. language that's obvious from a careful reading
> > of 2518. I personally prefer the following, more compact construction:
> >
> > Consistent with [RFC2518] the value of a dead property MUST be, and the
> > value of a live property SHOULD be, independent of the number of bindings to
> > its host resource or of the path submitted to PROPFIND.
>
> I personally would prefer to stay silent about the topic, but if
> everybody else is agreeing, I'll be happy to add one of these
> (preferrably the latter, shorter one).
>
> Feedback appreciated,
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 001CAACB85256F6A_=-- From w3c-dist-auth-request@w3.org Tue Dec 14 09:47:11 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03206 for ; Tue, 14 Dec 2004 09:47:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CeDuL-0004w6-PB for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Dec 2004 14:44:09 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CeDuJ-0004vB-Nc for w3c-dist-auth@listhub.w3.org; Tue, 14 Dec 2004 14:44:07 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CeDuJ-0004Ag-8z for w3c-dist-auth@w3.org; Tue, 14 Dec 2004 14:44:07 +0000 Received: (qmail invoked by alias); 14 Dec 2004 14:43:35 -0000 Received: from p50824B66.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.75.102) by mail.gmx.net (mp027) with SMTP; 14 Dec 2004 15:43:35 +0100 X-Authenticated: #1915285 Message-ID: <41BEFC15.9060002@gmx.de> Date: Tue, 14 Dec 2004 15:43:33 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: ejw@cs.ucsc.edu, "'webdav'" , w3c-dist-auth-request@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41BEFC15.9060002@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9198 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 14 Dec 2004 14:44:09 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > I also would prefer to remain silent, but I can live with this text > (I prefer the shorter version). OK, *where* should thie statement go...? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 14 12:40:36 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24934 for ; Tue, 14 Dec 2004 12:40:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CeGdp-0007Qr-Ut for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Dec 2004 17:39:17 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CeGdn-0007Pi-Q3 for w3c-dist-auth@listhub.w3.org; Tue, 14 Dec 2004 17:39:15 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by bart.w3.org with esmtp (Exim 4.34) id 1CeGdn-0006cK-Hv for w3c-dist-auth@w3.org; Tue, 14 Dec 2004 17:39:15 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iBEHcGlu000013 for ; Tue, 14 Dec 2004 09:38:19 -0800 (PST) Message-Id: <200412141738.iBEHcGlu000013@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'webdav'" Date: Tue, 14 Dec 2004 09:38:09 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <41BEFC15.9060002@gmx.de> Thread-Index: AcTh67he+HIhEnELTy2poLeeiCJiswAF7tuw X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/200412141738.iBEHcGlu000013@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9199 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 14 Dec 2004 17:39:17 +0000 Content-Transfer-Encoding: 7bit > OK, *where* should thie statement go...? My recommendation is a new section, titled, "PROPFIND and Bindings", placed either immediately before or after section 2.6. - Jim From w3c-dist-auth-request@w3.org Tue Dec 14 13:15:36 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29692 for ; Tue, 14 Dec 2004 13:15:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CeHCH-00053U-JE for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Dec 2004 18:14:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CeHCF-00052t-Jg for w3c-dist-auth@listhub.w3.org; Tue, 14 Dec 2004 18:14:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CeHC7-0000de-ND for w3c-dist-auth@w3.org; Tue, 14 Dec 2004 18:14:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iBEIEoEq017714; Tue, 14 Dec 2004 10:14:50 -0800 Date: Tue, 14 Dec 2004 10:14:50 -0800 Message-Id: <200412141814.iBEIEoEq017714@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/200412141814.iBEIEoEq017714@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9200 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 14 Dec 2004 18:14:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED ------- Additional Comments From julian.reschke@greenbytes.de 2004-12-14 10:14 ------- Added short paragraph making some statements about property behaviour when multiple bindings exist. See http://www.webdav.org/bind/draft-ietf-webdav-bind-issues.html#2.6_bindings_vs_properties. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Tue Dec 14 13:16:39 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29932 for ; Tue, 14 Dec 2004 13:16:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CeHDU-0005r5-8l for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Dec 2004 18:16:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CeHDU-0005qa-13 for w3c-dist-auth@listhub.w3.org; Tue, 14 Dec 2004 18:16:08 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CeHDM-0000tO-19 for w3c-dist-auth@w3.org; Tue, 14 Dec 2004 18:16:00 +0000 Received: (qmail invoked by alias); 14 Dec 2004 18:15:35 -0000 Received: from p50824B66.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.75.102) by mail.gmx.net (mp024) with SMTP; 14 Dec 2004 19:15:35 +0100 X-Authenticated: #1915285 Message-ID: <41BF2DC6.9070204@gmx.de> Date: Tue, 14 Dec 2004 19:15:34 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'webdav'" References: <200412141738.iBEHcGlu000013@cats-mx3.ucsc.edu> In-Reply-To: <200412141738.iBEHcGlu000013@cats-mx3.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41BF2DC6.9070204@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9201 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 14 Dec 2004 18:16:08 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: >>OK, *where* should thie statement go...? > > > My recommendation is a new section, titled, "PROPFIND and Bindings", placed > either immediately before or after section 2.6. OK, done in... . Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 16 10:00:39 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02248 for ; Thu, 16 Dec 2004 10:00:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cex5c-00005D-Gf for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Dec 2004 14:58:48 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cex5Z-0008Te-Tu; Thu, 16 Dec 2004 14:58:45 +0000 Received: from inet-mail1.oracle.com ([148.87.2.201]) by bart.w3.org with esmtp (Exim 4.34) id 1Cex5Z-0000KG-GI; Thu, 16 Dec 2004 14:58:45 +0000 Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iBGEwArH001420; Thu, 16 Dec 2004 06:58:10 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by inet-mail1.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iBGEw363001358; Thu, 16 Dec 2004 06:58:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id iBGEw2bO012260; Thu, 16 Dec 2004 07:58:02 -0700 Received: from [144.23.219.129] (dhcp-ca-montreal-144-23-219-129.ca.oracle.com [144.23.219.129]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iBGEvqWc012207 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 16 Dec 2004 07:57:53 -0700 Message-ID: <41C1A26C.5030602@oracle.com> Date: Thu, 16 Dec 2004 09:57:48 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: Julian Reschke CC: www-webdav-dasl@w3.org, ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org References: <41C0E450.2050004@oracle.com> <41C16635.9040400@gmx.de> <41C19013.3010409@oracle.com> <41C1957E.1060405@gmx.de> In-Reply-To: <41C1957E.1060405@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (bart.w3.org: domain of bernard.desruisseaux@oracle.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Response when no matching resource was found X-Archived-At: http://www.w3.org/mid/41C1A26C.5030602@oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9202 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Dec 2004 14:58:48 +0000 Content-Transfer-Encoding: 7bit [ For those not subscribed to www-webdav-dasl, I've copied the beginning of this thread at the end of this message. ] Julian Reschke wrote: > Bernard Desruisseaux wrote: > >> The declaration of the DAV:multistatus element in RFC 2518 >> (section 12.9) specifies that at least one DAV:response >> element must appear in a DAV:multistatus element. >> >> Is that an issue? > > > It's an issue with the original definition, which has (or should have > been) updated in RFC3253 and RFC2518bis. > > > Julian > It's "should have been". :-) RFC3253 simply makes reference to RFC 2518, Section 12.9 for the definition of multistatus. RFC2518bis (-06) still declare DAV:multistatus as follow: Do you want to open an issue for each document, and perhaps clarify in the search draft (although RFC2518bis should end up being published before search) ? Thanks, Bernard ---------------------- Julian Reschke wrote: > Bernard Desruisseaux wrote: > >> >> What is SEARCH supposed to return as a response when >> no matching resource was found? > > > > Status 207 with an empty DAV:multistatus response element. This should follow from...: > > > > > Julian > From w3c-dist-auth-request@w3.org Thu Dec 16 10:26:49 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04948 for ; Thu, 16 Dec 2004 10:26:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CexVx-0002RS-Ev for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Dec 2004 15:26:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CexVx-0002QM-0r for w3c-dist-auth@listhub.w3.org; Thu, 16 Dec 2004 15:26:01 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CexVo-0006X0-TE for w3c-dist-auth@w3.org; Thu, 16 Dec 2004 15:25:53 +0000 Received: (qmail invoked by alias); 16 Dec 2004 15:25:28 -0000 Received: from p50825F4A.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.95.74) by mail.gmx.net (mp001) with SMTP; 16 Dec 2004 16:25:28 +0100 X-Authenticated: #1915285 Message-ID: <41C1A8E6.6090204@gmx.de> Date: Thu, 16 Dec 2004 16:25:26 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Desruisseaux CC: www-webdav-dasl@w3.org, ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org References: <41C0E450.2050004@oracle.com> <41C16635.9040400@gmx.de> <41C19013.3010409@oracle.com> <41C1957E.1060405@gmx.de> <41C1A26C.5030602@oracle.com> In-Reply-To: <41C1A26C.5030602@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Response when no matching resource was found X-Archived-At: http://www.w3.org/mid/41C1A8E6.6090204@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9203 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Dec 2004 15:26:01 +0000 Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > [ For those not subscribed to www-webdav-dasl, I've copied > the beginning of this thread at the end of this message. ] > > Julian Reschke wrote: > >> Bernard Desruisseaux wrote: >> >>> The declaration of the DAV:multistatus element in RFC 2518 >>> (section 12.9) specifies that at least one DAV:response >>> element must appear in a DAV:multistatus element. >>> >>> Is that an issue? >> >> >> >> It's an issue with the original definition, which has (or should have >> been) updated in RFC3253 and RFC2518bis. >> >> >> Julian >> > > It's "should have been". :-) > > RFC3253 simply makes reference to RFC 2518, Section 12.9 > for the definition of multistatus. Indeed. This probably is OK because all REPORTs defined in RFC3253 indeed return at a minimum of one result. The new REPORTs on RFC3744 (ACL) may return empty sets and explicitly say so. > RFC2518bis (-06) still declare DAV:multistatus as follow: > > > > Do you want to open an issue for each document, and perhaps > clarify in the search draft (although RFC2518bis should end > up being published before search) ? The DTD fragments aren't normative anyway (thus RFC3744 doesn't attempt to modify them). It's arguable whether RFC2518 needs to be fixed. In a perfect world, RFC2518bis would be done soon and include the base definition for REPORT, but somehow I fear it won't happen in the foreseeable future. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Dec 16 11:57:56 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12960 for ; Thu, 16 Dec 2004 11:57:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ceyvp-0007YB-OH for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Dec 2004 16:56:49 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ceyvn-0007WU-Fo; Thu, 16 Dec 2004 16:56:47 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1Ceyvn-0001Uk-7e; Thu, 16 Dec 2004 16:56:47 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBGGuUaa029792 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Dec 2004 08:56:30 -0800 In-Reply-To: <41C1A26C.5030602@oracle.com> References: <41C0E450.2050004@oracle.com> <41C16635.9040400@gmx.de> <41C19013.3010409@oracle.com> <41C1957E.1060405@gmx.de> <41C1A26C.5030602@oracle.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <69E36370-4F83-11D9-83B0-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Julian Reschke , ietf-dav-versioning@w3.org, www-webdav-dasl@w3.org, w3c-dist-auth@w3.org From: Lisa Dusseault Date: Thu, 16 Dec 2004 08:56:21 -0800 To: Bernard Desruisseaux X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Response when no matching resource was found X-Archived-At: http://www.w3.org/mid/69E36370-4F83-11D9-83B0-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9204 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Dec 2004 16:56:49 +0000 Content-Transfer-Encoding: 7bit Do any servers currently do this in responses to REPORT or SEARCH? Have they run into problems with clients who don't know how to interpret the result if the element is empty? I wouldn't be surprised if there were problems. Lisa On Dec 16, 2004, at 6:57 AM, Bernard Desruisseaux wrote: > > [ For those not subscribed to www-webdav-dasl, I've copied > the beginning of this thread at the end of this message. ] > > Julian Reschke wrote: > >> Bernard Desruisseaux wrote: >>> The declaration of the DAV:multistatus element in RFC 2518 >>> (section 12.9) specifies that at least one DAV:response >>> element must appear in a DAV:multistatus element. >>> >>> Is that an issue? >> It's an issue with the original definition, which has (or should have >> been) updated in RFC3253 and RFC2518bis. >> Julian > > It's "should have been". :-) > > RFC3253 simply makes reference to RFC 2518, Section 12.9 > for the definition of multistatus. > > RFC2518bis (-06) still declare DAV:multistatus as follow: > > > > Do you want to open an issue for each document, and perhaps > clarify in the search draft (although RFC2518bis should end > up being published before search) ? > > Thanks, > Bernard > > ---------------------- > > Julian Reschke wrote: > > > Bernard Desruisseaux wrote: > > > >> > >> What is SEARCH supposed to return as a response when > >> no matching resource was found? > > > > > > > > Status 207 with an empty DAV:multistatus response element. This > should follow from...: > > > > > latest.html#rfc.section.2.3> > > > > > > Julian > > > > From w3c-dist-auth-request@w3.org Thu Dec 16 12:03:52 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13361 for ; Thu, 16 Dec 2004 12:03:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cez1v-0001e4-Kz for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Dec 2004 17:03:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cez1u-0001br-VG for w3c-dist-auth@listhub.w3.org; Thu, 16 Dec 2004 17:03:07 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1Cez1m-0004RO-J4 for w3c-dist-auth@w3.org; Thu, 16 Dec 2004 17:02:58 +0000 Received: (qmail invoked by alias); 16 Dec 2004 17:02:34 -0000 Received: from p50825F4A.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.95.74) by mail.gmx.net (mp012) with SMTP; 16 Dec 2004 18:02:34 +0100 X-Authenticated: #1915285 Message-ID: <41C1BFA7.3070204@gmx.de> Date: Thu, 16 Dec 2004 18:02:31 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Bernard Desruisseaux , ietf-dav-versioning@w3.org, www-webdav-dasl@w3.org, w3c-dist-auth@w3.org References: <41C0E450.2050004@oracle.com> <41C16635.9040400@gmx.de> <41C19013.3010409@oracle.com> <41C1957E.1060405@gmx.de> <41C1A26C.5030602@oracle.com> <69E36370-4F83-11D9-83B0-000A95B2BB72@osafoundation.org> In-Reply-To: <69E36370-4F83-11D9-83B0-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Response when no matching resource was found X-Archived-At: http://www.w3.org/mid/41C1BFA7.3070204@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9205 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Dec 2004 17:03:07 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Do any servers currently do this in responses to REPORT or SEARCH? > Have they run into problems with clients who don't know how to > interpret the result if the element is empty? I wouldn't > be surprised if there were problems. I would (be surprised). It's the nature of certain REPORTs and SEARCH that the result set can be empty, and a client that can't cope with it is simply broken. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 17 18:25:40 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03712 for ; Fri, 17 Dec 2004 18:25:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CfRRf-00035W-2X for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Dec 2004 23:23:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CfRRc-00034H-MR for w3c-dist-auth@listhub.w3.org; Fri, 17 Dec 2004 23:23:32 +0000 Received: from wproxy.gmail.com ([64.233.184.206]) by lisa.w3.org with esmtp (Exim 4.34) id 1CfRRU-0004mP-MR for w3c-dist-auth@w3.org; Fri, 17 Dec 2004 23:23:24 +0000 Received: by wproxy.gmail.com with SMTP id 69so138551wri for ; Fri, 17 Dec 2004 15:23:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=s+4OLMEPb6KM1FPEzyghxld2Y04Vs2nUj0bcivS3NxfDkqWOQjt6I30vLKDkIzSFv4FqOOnMIFjHpDFFzxQY21iUG3JNNajHM8Q947VmjhA0Ykevnea1GC0JOWpl3+An9DW0Kg5URXwOQDJ9D8c5/I1W1uroeXkGdtflBKsvKsk= Received: by 10.54.14.22 with SMTP id 22mr274120wrn; Fri, 17 Dec 2004 15:23:01 -0800 (PST) Received: by 10.54.8.32 with HTTP; Fri, 17 Dec 2004 15:23:01 -0800 (PST) Message-ID: <48803072041217152365bbfe7f@mail.gmail.com> Date: Fri, 17 Dec 2004 15:23:01 -0800 From: John Reese Reply-To: John Reese To: w3c-dist-auth@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of john.reese@gmail.com designates 64.233.184.206 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: question about MOVE and COPY overwriting folders X-Archived-At: http://www.w3.org/mid/48803072041217152365bbfe7f@mail.gmail.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9206 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 17 Dec 2004 23:23:35 +0000 Content-Transfer-Encoding: 7bit Good afternoon, WebDAV wg. I have a question about the interpretation of RFC 2518 -- I hope this is the right place to post it. If there's a better list, please let me know, and I subjunctively would apologize for posting here. I'm implementing a DAV server for a commercial product that exposes its content through various protocols, of which DAV is only one. There is some concern that the DAV semantics for MOVE and COPY with the overwrite header set to T are too dangerious for our repository... if the destination is a collection, it may be dangerous to do the equivalent of a depth-infinity DELETE before the MOVE or COPY, as section 8.8.4 and 8.9.3 dictate, because resources within a collection may have additional metadata, like version histories and so forth, as well as the equivalent of dead properties (although they won't be exposed as such through our DAV server in the first release). So, I have two questions: 1. given that overwriting a collection can have repurcussions for dead properties and so forth in general, why are MOVE and COPY defined as deleting the collections instead of (for example) a recursive per-resource overwrite that would retain properties on corresponding resources and remove those resources that were not in the source folder? 2. would refusing to service MOVE or COPY requests, regardless of the value of the Overwrite header, when the destination is a non-null collection resource (responding, for example, with a 405 Method Not Allowed to such requests), be compliant with the RFC, or would it conflict with the rules in section 8.8.4 and 8.9.3? Thanks. From w3c-dist-auth-request@w3.org Fri Dec 17 23:52:16 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02419 for ; Fri, 17 Dec 2004 23:52:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CfWYN-0004aq-5v for w3c-dist-auth-dist@listhub.w3.org; Sat, 18 Dec 2004 04:50:51 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CfWYK-0004aJ-NV for w3c-dist-auth@listhub.w3.org; Sat, 18 Dec 2004 04:50:48 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by bart.w3.org with esmtp (Exim 4.34) id 1CfWYK-0000Dy-Ic for w3c-dist-auth@w3.org; Sat, 18 Dec 2004 04:50:48 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iBI4oG8F006239 for ; Fri, 17 Dec 2004 23:50:16 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iBI4oG86225628 for ; Fri, 17 Dec 2004 23:50:16 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iBI4oGsg008747 for ; Fri, 17 Dec 2004 23:50:16 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iBI4oGH5008744 for ; Fri, 17 Dec 2004 23:50:16 -0500 In-Reply-To: <48803072041217152365bbfe7f@mail.gmail.com> To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 17 Dec 2004 23:49:57 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/17/2004 23:50:16, Serialize complete at 12/17/2004 23:50:16 Content-Type: multipart/alternative; boundary="=_alternative 001A8BDC85256F6E_=" Received-SPF: none (bart.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: question about MOVE and COPY overwriting folders X-Archived-At: http://www.w3.org/mid/OF6C2CEB57.C732EBBB-ON85256F6E.0019DC84-85256F6E.001A8BDF@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9207 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 18 Dec 2004 04:50:51 +0000 This is a multipart message in MIME format. --=_alternative 001A8BDC85256F6E_= Content-Type: text/plain; charset="US-ASCII" You should feel free to fail any operation that you feel is inappropriate for your repository. WRT the semantics of depth COPY, RFC-3253 modifies the definition of COPY to indicate that it overwrites the existing resource, rather than deleting it first (for the reasons that you identify), so you should feel free to implement COPY that way. On the other hand, MOVE with overwrite does delete the destination, so you should fail that operation if you don't like that behavior. Cheers, Geoff John wrote on 12/17/2004 06:23:01 PM: > > Good afternoon, WebDAV wg. I have a question about the interpretation > of RFC 2518 -- I hope this is the right place to post it. If there's > a better list, please let me know, and I subjunctively would apologize > for posting here. > > I'm implementing a DAV server for a commercial product that exposes > its content through various protocols, of which DAV is only one. > There is some concern that the DAV semantics for MOVE and COPY with > the overwrite header set to T are too dangerious for our repository... > if the destination is a collection, it may be dangerous to do the > equivalent of a depth-infinity DELETE before the MOVE or COPY, as > section 8.8.4 and 8.9.3 dictate, because resources within a collection > may have additional metadata, like version histories and so forth, as > well as the equivalent of dead properties (although they won't be > exposed as such through our DAV server in the first release). > > So, I have two questions: > > 1. given that overwriting a collection can have repurcussions for dead > properties and so forth in general, why are MOVE and COPY defined as > deleting the collections instead of (for example) a recursive > per-resource overwrite that would retain properties on corresponding > resources and remove those resources that were not in the source > folder? > > 2. would refusing to service MOVE or COPY requests, regardless of the > value of the Overwrite header, when the destination is a non-null > collection resource (responding, for example, with a 405 Method Not > Allowed to such requests), be compliant with the RFC, or would it > conflict with the rules in section 8.8.4 and 8.9.3? > > Thanks. > --=_alternative 001A8BDC85256F6E_= Content-Type: text/html; charset="US-ASCII"
You should feel free to fail any operation that you feel is inappropriate
for your repository.  WRT the semantics of depth COPY, RFC-3253 modifies
the definition of COPY to indicate that it overwrites the existing resource,
rather than deleting it first (for the reasons that you identify), so you
should feel free to implement COPY that way.  On the other hand, MOVE
with overwrite does delete the destination, so you should fail that operation
if you don't like that behavior.

Cheers,
Geoff

John wrote on 12/17/2004 06:23:01 PM:
>
> Good afternoon, WebDAV wg.  I have a question about the interpretation
> of RFC 2518 -- I hope this is the right place to post it.  If there's
> a better list, please let me know, and I subjunctively would apologize
> for posting here.
>
> I'm implementing a DAV server for a commercial product that exposes
> its content through various protocols, of which DAV is only one.
> There is some concern that the DAV semantics for MOVE and COPY with
> the overwrite header set to T are too dangerious for our repository...
> if the destination is a collection, it may be dangerous to do the
> equivalent of a depth-infinity DELETE before the MOVE or COPY, as
> section 8.8.4 and 8.9.3 dictate, because resources within a collection
> may have additional metadata, like version histories and so forth, as
> well as the equivalent of dead properties (although they won't be
> exposed as such through our DAV server in the first release).
>
> So, I have two questions:
>
> 1. given that overwriting a collection can have repurcussions for dead
> properties and so forth in general, why are MOVE and COPY defined as
> deleting the collections instead of (for example) a recursive
> per-resource overwrite that would retain properties on corresponding
> resources and remove those resources that were not in the source
> folder?
>
> 2. would refusing to service MOVE or COPY requests, regardless of the
> value of the Overwrite header, when the destination is a non-null
> collection resource (responding, for example, with a 405 Method Not
> Allowed to such requests), be compliant with the RFC, or would it
> conflict with the rules in section 8.8.4 and 8.9.3?
>
> Thanks.
>
--=_alternative 001A8BDC85256F6E_=-- From w3c-dist-auth-request@w3.org Sat Dec 18 14:38:03 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13229 for ; Sat, 18 Dec 2004 14:38:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CfkMM-0001jn-5U for w3c-dist-auth-dist@listhub.w3.org; Sat, 18 Dec 2004 19:35:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CfkMK-0001j5-2G for w3c-dist-auth@listhub.w3.org; Sat, 18 Dec 2004 19:35:20 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CfkMB-0005E5-Qb for w3c-dist-auth@w3.org; Sat, 18 Dec 2004 19:35:12 +0000 Received: (qmail invoked by alias); 18 Dec 2004 19:34:47 -0000 Received: from p54856DBE.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.109.190) by mail.gmx.net (mp012) with SMTP; 18 Dec 2004 20:34:47 +0100 X-Authenticated: #1915285 Message-ID: <41C48650.4080104@gmx.de> Date: Sat, 18 Dec 2004 20:34:40 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'webdav'" CC: Joe Hildebrand , ejw@cs.ucsc.edu, Lisa Dusseault , Ted Hardie References: <200412141738.iBEHcGlu000013@cats-mx3.ucsc.edu> <41BF2DC6.9070204@gmx.de> In-Reply-To: <41BF2DC6.9070204@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings X-Archived-At: http://www.w3.org/mid/41C48650.4080104@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9208 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 18 Dec 2004 19:35:22 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Jim Whitehead wrote: > >>> OK, *where* should thie statement go...? >> >> >> >> My recommendation is a new section, titled, "PROPFIND and Bindings", >> placed >> either immediately before or after section 2.6. > > > OK, done in... > . I haven't heard back from anybody, thus I'll assume that I can close the issue. Joe, Lisa; as far as I can tell all we're done except for where feedback to my latest entry would be appreciated. Other than that, I think we can either last-call draft -09 or submit the current draft as -10 and last-call that. It would be extremely good if we could do that early next week (with a four week last-call period), so that people interested have something to read over the holidays. Please provide feedback about how to proceed as soon as possible. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 21 05:46:14 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24312 for ; Tue, 21 Dec 2004 05:46:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CghVC-0007df-4j for w3c-dist-auth-dist@listhub.w3.org; Tue, 21 Dec 2004 10:44:26 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CghVA-0007cu-1w for w3c-dist-auth@listhub.w3.org; Tue, 21 Dec 2004 10:44:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CghV9-0002Ox-R1 for w3c-dist-auth@w3.org; Tue, 21 Dec 2004 10:44:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iBLAiM8w016355; Tue, 21 Dec 2004 02:44:22 -0800 Date: Tue, 21 Dec 2004 02:44:22 -0800 Message-Id: <200412211044.iBLAiM8w016355@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/200412211044.iBLAiM8w016355@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9209 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 21 Dec 2004 10:44:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Wed Dec 22 14:44:39 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26490 for ; Wed, 22 Dec 2004 14:44:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1ChCN5-0005JR-W6 for w3c-dist-auth-dist@listhub.w3.org; Wed, 22 Dec 2004 19:42:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1ChCN3-0005It-VH for w3c-dist-auth@listhub.w3.org; Wed, 22 Dec 2004 19:42:05 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.34) id 1ChCMv-00076B-AU for w3c-dist-auth@w3.org; Wed, 22 Dec 2004 19:41:57 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Dec 2004 11:41:29 -0800 In-Reply-To: <418692B6.9020207@gmx.de> References: <418692B6.9020207@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: WebDAV From: Brian Korver Date: Wed, 22 Dec 2004 11:41:29 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 22 Dec 2004 19:41:29.0531 (UTC) FILETIME=[3B7500B0:01C4E85E] Received-SPF: none (lisa.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: comments on draft-ietf-webdav-quota-04.txt, was: Fwd: I-D ACTION:draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/79939AA9-5451-11D9-8831-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9210 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 22 Dec 2004 19:42:07 +0000 Content-Transfer-Encoding: 7bit Julian, Thanks again for the very thorough read of the draft. I'll get an -05 out very soon that incorporates the fixes. Comments in-line.... -brian briank@xythos.com On Nov 1, 2004, at 11:47 AM, Julian Reschke wrote: > Brian, > > thanks for the new draft; getting rid of the authorability part > greatly simplifies the spec. > > Below are my updated comments. > > Best regards, Julian > > > > > Issues with draft-ietf-webdav-quota-04.txt > > Content > > 01-C01 Organization > 0425.html> > 0438.html> > > I think the draft could greatly benefit by a more clean separation of > (a) terminology, (b) protocol (property/error code) definition and (c) > examples. You've suggested a re-write in the past and I haven't seen any consensus that a re-write is necessary, especially at this late stage. This is a short spec, so let's just clean up the typos and move it along. > > Proposal for a outline: > > 1 Introduction/Notation/Terminology > 2 Additional live properties > 3 Modification to behaviour of existing methods (error marshalling) > 4...n Other standard RFC section > A (Appendix) Examples of how servers may implement quota > > I'm happy to help restructuring the document if this is just an > amount-of-work issue. > > > 01-C03 quota vs disk space > 0439.html> > 0460.html> > 0184.html> > 0193.html> > > The spec says that servers may expose physical disk limits as quota. > > a) This is incompatible with NFS from which we're borrowing the > semantics (it treats disk limits as a separate property, and so should > we) > > Update -04: this still appears in the text, but is less critical now > that authorability of the quota is gone. I'd still like to see the > working group make an explicit decision to keep this, because it's > IMHO clearly outside the scope of this spec (I'd prefer separate > properties). This was discussed on the list in the past, with no clear consensus except that you and I agree to disagree on this. Someone suggested that the problem was with using the term "quota" at all, but there wasn't any consensus that we should change that either. > > > 02-C01 Condition Name > > Use name of precondition, not failure description: > instead of . There was no clear consensus when I asked for a show of hands on the list on whether this change was desired/required. > > > 03-C01 spec organization/semantics > > Back when draft 02 was published, we had a mailing list discussion > about using the term "quota space" to simplify the rest of the spec. > > 0294.html> > > Unfortunately, neither was the discussion was finished nor do I see a > change in the spec. The following (mostly) editorial changes will all be cleaned up in -05: > > > 04-C01, section 1.2, requirements > > "WebDAV servers based on [RFC2518] have been implemented and > deployed > with quota restrictions on collections and users, so it makes sense > to standardize this functionality to improve user experience and > client interoperability. This specification requires WebDAV because > it requires PROPFIND support and relies on the WebDAV definition of > collections and properties, including the definitions for live and > protected properties." > > RFC2518 doesn't define "protected" property, so a reference to > RFC3253, section 1.4.2 seems to be in order. > > > 04-C02, section 1.2, requirements > > "o Sometimes the storage service is provided free, but the storage > service provider has limited storage space (e.g. www.example.com > and university-provided student accounts)" > > This used to refer to www.sharemation.com. As it now says > "example.com" it seems to have lost it's meaning. Maybe replace by a > generic description of a site that offers storage to registered users. > > > 04-C03, section 1.2, requirements > > "In addition to displaying the quota-available and quota-used on > collections, this specification does not forbid these properties on > any resource." > > This sentence is a bit confusing, in particular as section 2 > recommends supporting the property on all resources. Just remove it. > > > 04-C04, section 2, solution overview > > "The approach to meeting the requirements and scenarios outlined > above > is to define three live properties." > > *Two* properties. > > > 04-C05, section 2, solution overview > > "This specification can be met on > a server by implementing both quota-available and quota-used on > collections only. Implementing both quota-available and quota- used > on all resources is RECOMMENDED." > > Fix whitespace ("quota- used") and property names. Also consider using > the > "DAV:propertname" syntax used in other specs. > > > 04-C05, section 2, solution overview > > "The quota-available and quota-used definitions below borrow heavily > from the quota definitions in the NFS [RFC3010] specification." > > Fix property names and NFS reference (occurs several additional times). > > > 04-C06, section 3, DAV:quota-available-bytes > > "The DAV:quota-available-bytes property value is the value in octets > representing the amount of additional disk space beyond the current > allocation that can be allocated to this file or directory before > further allocations will be refused. It is understood that this > space may be consumed by allocations to other files or directories." > > Replace "file or directory" by "resource". Note that neither "file" or > "directory" exist in WebDAV terminology. (same in section 4) > > > 04-C07, section 3, DAV:quota-available-bytes > > "Support for this property is REQUIRED on collections, and OPTIONAL > on > other resources. A server SHOULD implement this property for each > resource that has the DAV:quota-used-bytes property." > > What's the motivation for the distinction? (same in section 4) > > > 04-C08, section 3, DAV:quota-available-bytes > > "The value of this property is protected. A 403 Forbidden response > is > RECOMMENDED for attempts to write a protected property." > > RFC3253 defines the precondition > "DAV:cannot-modify-protected-property". > > > 04-C09, section 5, Examples > > Bad XML in response (at least one missing namespace prefix, you may > want to run the examples through a parser to check for more). > > > 04-C10, section 6 > > "WebDAV [RFC2518] defines the status code 507 (Insufficient Storage). > This status code SHOULD be used when a client request (e.g. a PUT, > PROPFIND, MKCOL, MOVE or COPY) is forbidden because it would exceed > their allotted quota." > > s/is forbidden/fails/ (to avoid confusion with ACLs) > > > 04-C11, section 7 > > "The total size of a collection, DAV:quota-used-bytes, is not > necessarily a sum of the DAV:getcontentlength properties for > resources stored in the collection." > > Actually, it won't be in most cases I'm aware of. Please either > rephrase it (so this doesn't sound like an edge case) or drop the > point. > > > 04-C12, section 8 > > "If a server chooses to make the DAV:quota-assigned-bytes writable by > clients with sufficient authorization, then it is opening up a > certain amount of near-administration functionality to clients. > However, it is not required for the DAV:quota-assigned-bytes > property > to be writeable by any clients, so a server can easily avoid this > consideration." > > Right now it's a SHOULD-level requirement to make the property > protected, so I wouldn't expect the spec to discuss the case where a > server breaks that requirement. > > > > Editorial: > > 03-E02 outdated reference to NFS spec (3010 -> 3530) > > 0197.html> > > Update -04: the reference has been updated, but only partly (wrong > date, and > still using the ID "RFC3010"). Replace by: > > [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., > Beame, C., Eisler, M. and D. Noveck, "Network File System > (NFS) version 4 Protocol", RFC 3530, April 2003. > > > 04-E01 Abstract > > s/This Internet-Draft discusses/This document discusses/ > > > 04-E02 References > > Reference to RFC2026 doesn't seem to be used anywhere. > > > > From w3c-dist-auth-request@w3.org Wed Dec 22 15:29:50 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00494 for ; Wed, 22 Dec 2004 15:29:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1ChD6L-0000wO-4v for w3c-dist-auth-dist@listhub.w3.org; Wed, 22 Dec 2004 20:28:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1ChD6I-0000vm-Bg for w3c-dist-auth@listhub.w3.org; Wed, 22 Dec 2004 20:28:50 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1ChD69-0004JA-L1 for w3c-dist-auth@w3.org; Wed, 22 Dec 2004 20:28:41 +0000 Received: (qmail invoked by alias); 22 Dec 2004 20:28:14 -0000 Received: from pD9535066.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.80.102) by mail.gmx.net (mp002) with SMTP; 22 Dec 2004 21:28:14 +0100 X-Authenticated: #1915285 Message-ID: <41C9D8C4.6060105@gmx.de> Date: Wed, 22 Dec 2004 21:27:48 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: WebDAV References: <418692B6.9020207@gmx.de> <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> In-Reply-To: <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: comments on draft-ietf-webdav-quota-04.txt, was: Fwd: I-D ACTION:draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/41C9D8C4.6060105@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9211 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 22 Dec 2004 20:28:53 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > Julian, > > Thanks again for the very thorough read of the draft. I'll get > an -05 out very soon that incorporates the fixes. > > Comments in-line.... > > -brian > briank@xythos.com > > > > On Nov 1, 2004, at 11:47 AM, Julian Reschke wrote: > >> Brian, >> >> thanks for the new draft; getting rid of the authorability part >> greatly simplifies the spec. >> >> Below are my updated comments. >> >> Best regards, Julian >> >> >> >> >> Issues with draft-ietf-webdav-quota-04.txt >> >> Content >> >> 01-C01 Organization >> >> >> >> I think the draft could greatly benefit by a more clean separation of >> (a) terminology, (b) protocol (property/error code) definition and >> (c) examples. > > > You've suggested a re-write in the past and I haven't seen > any consensus that a re-write is necessary, especially at > this late stage. This is a short spec, so let's just clean > up the typos and move it along. Well, all I can say is that I feel the spec would benefit from that rewrite; and I have offered assistance to do that. However, it sounds a bit strange to first ignore the suggestion for over a year, only then to state that it's too late to make that change. >> Proposal for a outline: >> >> 1 Introduction/Notation/Terminology >> 2 Additional live properties >> 3 Modification to behaviour of existing methods (error marshalling) >> 4...n Other standard RFC section >> A (Appendix) Examples of how servers may implement quota >> >> I'm happy to help restructuring the document if this is just an >> amount-of-work issue. >> >> >> 01-C03 quota vs disk space >> >> >> >> >> >> The spec says that servers may expose physical disk limits as quota. >> >> a) This is incompatible with NFS from which we're borrowing the >> semantics (it treats disk limits as a separate property, and so >> should we) >> >> Update -04: this still appears in the text, but is less critical now >> that authorability of the quota is gone. I'd still like to see the >> working group make an explicit decision to keep this, because it's >> IMHO clearly outside the scope of this spec (I'd prefer separate >> properties). > > > This was discussed on the list in the past, with no clear consensus except > that you and I agree to disagree on this. Someone suggested that the > problem was with using the term "quota" at all, but there wasn't any > consensus that we should change that either. I'd say the working group needs to make an explicit decision whether disk limits are in-scope or not. If they are in, we're using the wrong terminology here and we should fix that. >> 02-C01 Condition Name >> >> Use name of precondition, not failure description: >> instead of . > > > There was no clear consensus when I asked for a show of hands on the list > on whether this change was desired/required. I can't recall you asking; but I'm sure you can point to a message in the mailing list archive? Anyway, *I* recall that you agreed to change it () and the only disagreement came from Lisa (in , but she said she didn't want to delay the draft because of that). That being said: you are re-using terminology and syntax from RFC3253 in a slighty incompatible way. Thus, I think it's reasonable to ask *you* to show that there is consensus for introducing this inconsistency. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Dec 22 15:37:10 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00980 for ; Wed, 22 Dec 2004 15:37:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1ChDDm-0004Ai-TB for w3c-dist-auth-dist@listhub.w3.org; Wed, 22 Dec 2004 20:36:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1ChDDm-00049g-3L; Wed, 22 Dec 2004 20:36:34 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.34) id 1ChDDd-0008Pf-Kp; Wed, 22 Dec 2004 20:36:25 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iBMKa08F007262; Wed, 22 Dec 2004 15:36:00 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iBMKa0Rl273088; Wed, 22 Dec 2004 15:36:00 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iBMKZxTZ028960; Wed, 22 Dec 2004 15:36:00 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iBMKZxjE028957; Wed, 22 Dec 2004 15:35:59 -0500 In-Reply-To: <41C9D8C4.6060105@gmx.de> To: Julian Reschke Cc: Brian Korver , WebDAV , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 22 Dec 2004 15:36:00 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/22/2004 15:35:59, Serialize complete at 12/22/2004 15:35:59 Content-Type: multipart/alternative; boundary="=_alternative 0071296205256F72_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: precondition naming [was Re: comments on draft-ietf-webdav-quota-04.txt] X-Archived-At: http://www.w3.org/mid/OF9DDD8C9B.980A5359-ON85256F72.0070DC0F-05256F72.00712966@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9212 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 22 Dec 2004 20:36:34 +0000 This is a multipart message in MIME format. --=_alternative 0071296205256F72_= Content-Type: text/plain; charset="US-ASCII" I also do not recall a show-of-hands request on this topic, but if there had been one, I would have said that no compelling case has been made to diverge from the conventions of RFC3253, and therefore those conventions should be maintained. Cheers, Geoff Julian wrote on 12/22/2004 03:27:48 PM: > > Brian Korver wrote: > >> Use name of precondition, not failure description: > >> instead of . > > > > > > There was no clear consensus when I asked for a show of hands on the list > > on whether this change was desired/required. > > I can't recall you asking; but I'm sure you can point to a message in > the mailing list archive? > > Anyway, *I* recall that you agreed to change it > () > and the only disagreement came from Lisa (in > , > but she said she didn't want to delay the draft because of that). > > That being said: you are re-using terminology and syntax from RFC3253 in > a slighty incompatible way. Thus, I think it's reasonable to ask *you* > to show that there is consensus for introducing this inconsistency. --=_alternative 0071296205256F72_= Content-Type: text/html; charset="US-ASCII"
I also do not recall a show-of-hands request on this topic,
but if there had been one, I would have said that no compelling
case has been made to diverge from the conventions of RFC3253,
and therefore those conventions should be maintained.

Cheers,
Geoff

Julian wrote on 12/22/2004 03:27:48 PM:
>
> Brian Korver wrote:

> >> Use name of precondition, not failure description:  
> >> <quota-not-exceeded/> instead of <storage-quota-reached/>.
> >
> >
> > There was no clear consensus when I asked for a show of hands on the  list
> > on whether this change was desired/required.
>
> I can't recall you asking; but I'm sure you can point to a message in
> the mailing list archive?
>
> Anyway, *I* recall that you agreed to change it
> (<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0107.html>)
> and the only disagreement came from Lisa (in
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0109.html>,
> but she said she didn't want to delay the draft because of that).
>
> That being said: you are re-using terminology and syntax from RFC3253 in
> a slighty incompatible way. Thus, I think it's reasonable to ask *you*
> to show that there is consensus for introducing this inconsistency.

 --=_alternative 0071296205256F72_=-- From w3c-dist-auth-request@w3.org Thu Dec 23 14:36:47 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12775 for ; Thu, 23 Dec 2004 14:36:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1ChYho-0007Si-ES for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Dec 2004 19:33:00 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1ChYhm-0007SC-A2 for w3c-dist-auth@listhub.w3.org; Thu, 23 Dec 2004 19:32:58 +0000 Received: from cats-mx1.ucsc.edu ([128.114.125.34]) by bart.w3.org with esmtp (Exim 4.34) id 1ChYhm-00084c-6v for w3c-dist-auth@w3.org; Thu, 23 Dec 2004 19:32:58 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx1.ucsc.edu (8.13.1/8.13.1) with ESMTP id iBNJVwH5007860; Thu, 23 Dec 2004 11:32:09 -0800 (PST) Message-Id: <200412231932.iBNJVwH5007860@cats-mx1.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Brian Korver'" , "'WebDAV'" Date: Thu, 23 Dec 2004 11:31:48 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcToZfE/VnqAiV7iSoeuotpn11rjDQAv/Y2A X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: precondition naming [was Re: comments on draft-ietf-webdav-quota-04.txt] X-Archived-At: http://www.w3.org/mid/200412231932.iBNJVwH5007860@cats-mx1.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9213 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 23 Dec 2004 19:33:00 +0000 Content-Transfer-Encoding: 7bit Geoff Clemm writes: > I also do not recall a show-of-hands request on this topic, > but if there had been one, I would have said that no compelling > case has been made to diverge from the conventions of RFC3253, > and therefore those conventions should be maintained. +1 - Jim From w3c-dist-auth-request@w3.org Thu Dec 23 20:30:29 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16011 for ; Thu, 23 Dec 2004 20:30:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CheFO-0000JE-CP for w3c-dist-auth-dist@listhub.w3.org; Fri, 24 Dec 2004 01:28:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CheFM-0000I9-4f for w3c-dist-auth@listhub.w3.org; Fri, 24 Dec 2004 01:28:00 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.34) id 1CheFD-0002bg-JJ for w3c-dist-auth@w3.org; Fri, 24 Dec 2004 01:27:51 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Dec 2004 17:27:25 -0800 In-Reply-To: <41C9D8C4.6060105@gmx.de> References: <418692B6.9020207@gmx.de> <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> <41C9D8C4.6060105@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDAV From: Brian Korver Date: Thu, 23 Dec 2004 17:27:25 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 24 Dec 2004 01:27:25.0829 (UTC) FILETIME=[B9967B50:01C4E957] Received-SPF: none (lisa.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: comments on draft-ietf-webdav-quota-04.txt, was: Fwd: I-D ACTION:draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/F7D4C901-554A-11D9-8831-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9214 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 24 Dec 2004 01:28:02 +0000 Content-Transfer-Encoding: 7bit On Dec 22, 2004, at 12:27 PM, Julian Reschke wrote: > Brian Korver wrote: >> Julian, >> Thanks again for the very thorough read of the draft. I'll get >> an -05 out very soon that incorporates the fixes. >> Comments in-line.... >> -brian >> briank@xythos.com >> On Nov 1, 2004, at 11:47 AM, Julian Reschke wrote: >>> Brian, >>> >>> thanks for the new draft; getting rid of the authorability part >>> greatly simplifies the spec. >>> >>> Below are my updated comments. >>> >>> Best regards, Julian >>> >>> >>> >>> >>> Issues with draft-ietf-webdav-quota-04.txt >>> >>> Content >>> >>> 01-C01 Organization >>> >> 0425.html> >>> >> 0438.html> >>> >>> I think the draft could greatly benefit by a more clean separation >>> of (a) terminology, (b) protocol (property/error code) definition >>> and (c) examples. >> You've suggested a re-write in the past and I haven't seen >> any consensus that a re-write is necessary, especially at >> this late stage. This is a short spec, so let's just clean >> up the typos and move it along. > > Well, all I can say is that I feel the spec would benefit from that > rewrite; and I have offered assistance to do that. However, it sounds > a bit strange to first ignore the suggestion for over a year, only > then to state that it's too late to make that change. > >>> Proposal for a outline: >>> >>> 1 Introduction/Notation/Terminology >>> 2 Additional live properties >>> 3 Modification to behaviour of existing methods (error marshalling) >>> 4...n Other standard RFC section >>> A (Appendix) Examples of how servers may implement quota >>> >>> I'm happy to help restructuring the document if this is just an >>> amount-of-work issue. >>> >>> >>> 01-C03 quota vs disk space >>> >> 0439.html> >>> >> 0460.html> >>> >> 0184.html> >>> >> 0193.html> >>> >>> The spec says that servers may expose physical disk limits as quota. >>> >>> a) This is incompatible with NFS from which we're borrowing the >>> semantics (it treats disk limits as a separate property, and so >>> should we) >>> >>> Update -04: this still appears in the text, but is less critical now >>> that authorability of the quota is gone. I'd still like to see the >>> working group make an explicit decision to keep this, because it's >>> IMHO clearly outside the scope of this spec (I'd prefer separate >>> properties). >> This was discussed on the list in the past, with no clear consensus >> except >> that you and I agree to disagree on this. Someone suggested that the >> problem was with using the term "quota" at all, but there wasn't any >> consensus that we should change that either. > > I'd say the working group needs to make an explicit decision whether > disk limits are in-scope or not. If they are in, we're using the wrong > terminology here and we should fix that. With my author hat on I might agree, but with my this-is-already-deployed hat on I'm voting for leaving the spec as-is. I haven't exactly noticed an overwhelming mandate for changing "quota" to something else. > >>> 02-C01 Condition Name >>> >>> Use name of precondition, not failure description: >>> instead of . >> There was no clear consensus when I asked for a show of hands on the >> list >> on whether this change was desired/required. > > I can't recall you asking; but I'm sure you can point to a message in > the mailing list archive? > > Anyway, *I* recall that you agreed to change it > ( 0107.html>) and the only disagreement came from Lisa (in > 0109.html>, but she said she didn't want to delay the draft because of > that). Right, those are the emails. I agree with Lisa that I don't feel it's worth delaying the draft over either. Are you saying that you would object to the draft moving forward if your suggested change isn't made? > > That being said: you are re-using terminology and syntax from RFC3253 > in a slighty incompatible way. Thus, I think it's reasonable to ask > *you* to show that there is consensus for introducing this > inconsistency. > > > ... > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Dec 24 07:00:54 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09621 for ; Fri, 24 Dec 2004 07:00:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cho50-0001A7-0J for w3c-dist-auth-dist@listhub.w3.org; Fri, 24 Dec 2004 11:57:58 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cho4x-00019Z-SJ for w3c-dist-auth@listhub.w3.org; Fri, 24 Dec 2004 11:57:55 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cho4y-0000De-1T for w3c-dist-auth@w3.org; Fri, 24 Dec 2004 11:57:56 +0000 Received: (qmail invoked by alias); 24 Dec 2004 11:57:22 -0000 Received: from pD9E515CE.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.21.206) by mail.gmx.net (mp006) with SMTP; 24 Dec 2004 12:57:22 +0100 X-Authenticated: #1915285 Message-ID: <41CC041B.5050102@gmx.de> Date: Fri, 24 Dec 2004 12:57:15 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: WebDAV References: <418692B6.9020207@gmx.de> <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> <41C9D8C4.6060105@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: qutoa vs disk space, was: comments on draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/41CC041B.5050102@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9215 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 24 Dec 2004 11:57:58 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: >>> This was discussed on the list in the past, with no clear consensus >>> except >>> that you and I agree to disagree on this. Someone suggested that the >>> problem was with using the term "quota" at all, but there wasn't any >>> consensus that we should change that either. >> >> >> I'd say the working group needs to make an explicit decision whether >> disk limits are in-scope or not. If they are in, we're using the >> wrong terminology here and we should fix that. > > > With my author hat on I might agree, but with my this-is-already-deployed > hat on I'm voting for leaving the spec as-is. I haven't exactly noticed > an overwhelming mandate for changing "quota" to something else. > ... Well, the "this-is-already-deployed" point of view hardly is relevant here. This spec has been under discussion for over two years now, and progress on it has been extremely slow. If being completely compatible to the stuff that is already deployed was important, I would have expected that more energy would have been invested to actually get the spec out of the door. That being said; there shouldn't be any problem at all migrating existing implementations to new terminology/property names. The server implementations can continue to support the old properties until the relevant clients have been upgraded. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 24 07:02:28 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09756 for ; Fri, 24 Dec 2004 07:02:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cho7u-0001z3-5z for w3c-dist-auth-dist@listhub.w3.org; Fri, 24 Dec 2004 12:00:58 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cho7t-0001yZ-Sy for w3c-dist-auth@listhub.w3.org; Fri, 24 Dec 2004 12:00:57 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cho7u-0000xq-3j for w3c-dist-auth@w3.org; Fri, 24 Dec 2004 12:00:58 +0000 Received: (qmail invoked by alias); 24 Dec 2004 12:00:25 -0000 Received: from pD9E515CE.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.21.206) by mail.gmx.net (mp006) with SMTP; 24 Dec 2004 13:00:25 +0100 X-Authenticated: #1915285 Message-ID: <41CC04D3.4070701@gmx.de> Date: Fri, 24 Dec 2004 13:00:19 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: WebDAV References: <418692B6.9020207@gmx.de> <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> <41C9D8C4.6060105@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Condition names, was: comments on draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/41CC04D3.4070701@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9216 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 24 Dec 2004 12:00:58 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: >>>> 02-C01 Condition Name >>>> >>>> Use name of precondition, not failure description: >>>> instead of . >>> >>> There was no clear consensus when I asked for a show of hands on >>> the list >>> on whether this change was desired/required. >> >> >> I can't recall you asking; but I'm sure you can point to a message in >> the mailing list archive? >> >> Anyway, *I* recall that you agreed to change it >> (> 0107.html>) and the only disagreement came from Lisa (in >> > 0109.html>, but she said she didn't want to delay the draft because >> of that). > > > Right, those are the emails. > > I agree with Lisa that I don't feel it's worth delaying the draft > over either. Are you saying that you would object to the draft > moving forward if your suggested change isn't made? > ... I'm convinced that re-using RFC3253 terminology in an inconsistent way is a Very Bad Idea, in particular if there doesn't seem to be any rationale for it except "personal preference". Thus, I'll continue to object, and, as far as I can tell from the previous mails, I seem to be part of the WG majority here. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Dec 24 12:09:36 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29071 for ; Fri, 24 Dec 2004 12:09:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Chsu3-0004h4-2x for w3c-dist-auth-dist@listhub.w3.org; Fri, 24 Dec 2004 17:06:59 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Chsu0-0004g1-Nu for w3c-dist-auth@listhub.w3.org; Fri, 24 Dec 2004 17:06:56 +0000 Received: from mail2.speakeasy.net ([216.254.0.202]) by bart.w3.org with esmtp (Exim 4.34) id 1Chsu1-0004Tg-A2 for w3c-dist-auth@w3.org; Fri, 24 Dec 2004 17:06:57 +0000 Received: (qmail 2478 invoked from network); 24 Dec 2004 17:06:54 -0000 Received: from adsl-63-194-88-161.dsl.snfc21.pacbell.net (HELO cse.ucsc.edu) (elias@[63.194.88.161]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 24 Dec 2004 17:06:54 -0000 Message-ID: <41CC4CAC.7060503@cse.ucsc.edu> Date: Fri, 24 Dec 2004 09:06:52 -0800 From: Elias Sinderson User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV References: <418692B6.9020207@gmx.de> <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> <41C9D8C4.6060105@gmx.de> <41CC04D3.4070701@gmx.de> In-Reply-To: <41CC04D3.4070701@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (bart.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Condition names, was: comments on draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/41CC4CAC.7060503@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9217 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 24 Dec 2004 17:06:59 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > I'm convinced that re-using RFC3253 terminology in an inconsistent way > is a Very Bad Idea [...] Reusing /any/ terminology in an inconsistent way is a bad idea -- it leads to confusion among implementors, makes the ensuing discussions overly cumbersome, etc. Elias From w3c-dist-auth-request@w3.org Mon Dec 27 16:53:44 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07009 for ; Mon, 27 Dec 2004 16:53:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cj2l7-0002rq-1L for w3c-dist-auth-dist@listhub.w3.org; Mon, 27 Dec 2004 21:50:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cj2l4-0002rB-KX for w3c-dist-auth@listhub.w3.org; Mon, 27 Dec 2004 21:50:30 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cj2kv-0000hO-Tz for w3c-dist-auth@w3.org; Mon, 27 Dec 2004 21:50:22 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.101] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBRLoMaa017782 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 27 Dec 2004 13:50:25 -0800 In-Reply-To: <41CC4CAC.7060503@cse.ucsc.edu> References: <418692B6.9020207@gmx.de> <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> <41C9D8C4.6060105@gmx.de> <41CC04D3.4070701@gmx.de> <41CC4CAC.7060503@cse.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <49455BF2-5851-11D9-981D-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDAV From: Lisa Dusseault Date: Mon, 27 Dec 2004 13:50:12 -0800 To: Elias Sinderson X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Condition names, was: comments on draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/49455BF2-5851-11D9-981D-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9218 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 27 Dec 2004 21:50:33 +0000 Content-Transfer-Encoding: 7bit I generally agree that specification writers should re-use terminology consistently -- great sentiment. However that isn't even what we're talking about here. - This isn't a case of re-using any terminology -- the issue is a set of new error codes with a different naming style. - We could go for a consistent style with RFC3253, however I found the RFC3253 style confusing and prefer the quota style as-is - The style used in the quota draft is consistent with RFC2616 style of describing errors in text. E.g. HTTP generally describes the error ("NOT FOUND") rather than the precondition ("RESOURCE MUST EXIST"). So it's RFC3253 that made the departure in style. Lisa On Dec 24, 2004, at 9:06 AM, Elias Sinderson wrote: > > Julian Reschke wrote: > >> I'm convinced that re-using RFC3253 terminology in an inconsistent >> way is a Very Bad Idea [...] > > Reusing /any/ terminology in an inconsistent way is a bad idea -- it > leads to confusion among implementors, makes the ensuing discussions > overly cumbersome, etc. > > > Elias > From w3c-dist-auth-request@w3.org Mon Dec 27 16:54:18 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07053 for ; Mon, 27 Dec 2004 16:54:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cj2mo-0003G0-P0 for w3c-dist-auth-dist@listhub.w3.org; Mon, 27 Dec 2004 21:52:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cj2mm-0003F1-0Y for w3c-dist-auth@listhub.w3.org; Mon, 27 Dec 2004 21:52:16 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cj2md-00018U-8z for w3c-dist-auth@w3.org; Mon, 27 Dec 2004 21:52:07 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.101] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBRLpsaa017912 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 27 Dec 2004 13:51:58 -0800 In-Reply-To: <41CC041B.5050102@gmx.de> References: <418692B6.9020207@gmx.de> <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> <41C9D8C4.6060105@gmx.de> <41CC041B.5050102@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <801A8603-5851-11D9-981D-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Brian Korver , WebDAV From: Lisa Dusseault Date: Mon, 27 Dec 2004 13:51:44 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: qutoa vs disk space, was: comments on draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/801A8603-5851-11D9-981D-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9219 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 27 Dec 2004 21:52:18 +0000 Content-Transfer-Encoding: 7bit The WG has already had extensive discussions on the names of the properties and I see no compelling reason to change them. Lisa On Dec 24, 2004, at 3:57 AM, Julian Reschke wrote: > > Brian Korver wrote: >>>> This was discussed on the list in the past, with no clear consensus >>>> except >>>> that you and I agree to disagree on this. Someone suggested that >>>> the >>>> problem was with using the term "quota" at all, but there wasn't any >>>> consensus that we should change that either. >>> >>> >>> I'd say the working group needs to make an explicit decision whether >>> disk limits are in-scope or not. If they are in, we're using the >>> wrong terminology here and we should fix that. >> With my author hat on I might agree, but with my >> this-is-already-deployed >> hat on I'm voting for leaving the spec as-is. I haven't exactly >> noticed >> an overwhelming mandate for changing "quota" to something else. >> ... > > Well, the "this-is-already-deployed" point of view hardly is relevant > here. This spec has been under discussion for over two years now, and > progress on it has been extremely slow. If being completely compatible > to the stuff that is already deployed was important, I would have > expected that more energy would have been invested to actually get the > spec out of the door. > > That being said; there shouldn't be any problem at all migrating > existing implementations to new terminology/property names. The server > implementations can continue to support the old properties until the > relevant clients have been upgraded. > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Mon Dec 27 18:54:36 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19318 for ; Mon, 27 Dec 2004 18:54:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cj4e2-0001gL-KE for w3c-dist-auth-dist@listhub.w3.org; Mon, 27 Dec 2004 23:51:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cj4e0-0001fK-BZ for w3c-dist-auth@listhub.w3.org; Mon, 27 Dec 2004 23:51:20 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1Cj4dr-0000oR-IZ for w3c-dist-auth@w3.org; Mon, 27 Dec 2004 23:51:11 +0000 Received: (qmail invoked by alias); 27 Dec 2004 23:50:47 -0000 Received: from pD9E5102A.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.16.42) by mail.gmx.net (mp013) with SMTP; 28 Dec 2004 00:50:47 +0100 X-Authenticated: #1915285 Message-ID: <41D09FD2.5030407@gmx.de> Date: Tue, 28 Dec 2004 00:50:42 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Elias Sinderson , WebDAV References: <418692B6.9020207@gmx.de> <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> <41C9D8C4.6060105@gmx.de> <41CC04D3.4070701@gmx.de> <41CC4CAC.7060503@cse.ucsc.edu> <49455BF2-5851-11D9-981D-000A95B2BB72@osafoundation.org> In-Reply-To: <49455BF2-5851-11D9-981D-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Condition names, was: comments on draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/41D09FD2.5030407@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9220 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 27 Dec 2004 23:51:22 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > I generally agree that specification writers should re-use terminology > consistently -- great sentiment. However that isn't even what we're > talking about here. > - This isn't a case of re-using any terminology -- the issue is a set > of new error codes with a different naming style. With both a naming and usage style that is inconsistent with the spec that introduced the syntax. If you don't want to use it consistently, *please* don't use it at all. > - We could go for a consistent style with RFC3253, however I found the > RFC3253 style confusing and prefer the quota style as-is We know that, but as far as I can tell everybody except you and Brian clearly disagrees. > - The style used in the quota draft is consistent with RFC2616 style of > describing errors in text. E.g. HTTP generally describes the error > ("NOT FOUND") rather than the precondition ("RESOURCE MUST EXIST"). Lisa, we're not talking about HTTP status codes, but about condition names used inside the DAV:error element defined in RFC3253. > So it's RFC3253 that made the departure in style. You may argue that, but in that case the right way to approach the issue is not to re-use RFC3253's syntax at all. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Dec 27 19:42:51 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19319 for ; Mon, 27 Dec 2004 18:54:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cj4ep-0001rS-1W for w3c-dist-auth-dist@listhub.w3.org; Mon, 27 Dec 2004 23:52:11 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cj4eo-0001qa-NO for w3c-dist-auth@listhub.w3.org; Mon, 27 Dec 2004 23:52:10 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cj4en-000671-Un for w3c-dist-auth@w3.org; Mon, 27 Dec 2004 23:52:10 +0000 Received: (qmail invoked by alias); 27 Dec 2004 23:51:37 -0000 Received: from pD9E5102A.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.16.42) by mail.gmx.net (mp002) with SMTP; 28 Dec 2004 00:51:37 +0100 X-Authenticated: #1915285 Message-ID: <41D0A006.5050206@gmx.de> Date: Tue, 28 Dec 2004 00:51:34 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Brian Korver , WebDAV References: <418692B6.9020207@gmx.de> <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> <41C9D8C4.6060105@gmx.de> <41CC041B.5050102@gmx.de> <801A8603-5851-11D9-981D-000A95B2BB72@osafoundation.org> In-Reply-To: <801A8603-5851-11D9-981D-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: qutoa vs disk space, was: comments on draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/41D0A006.5050206@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9221 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 27 Dec 2004 23:52:11 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > The WG has already had extensive discussions on the names of the > properties and I see no compelling reason to change them. I also see no compelling reason to change them as long as they are used for quotas, which are *not* disk limits. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 28 04:59:01 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11161 for ; Tue, 28 Dec 2004 04:59:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CjE4m-0008BP-1T for w3c-dist-auth-dist@listhub.w3.org; Tue, 28 Dec 2004 09:55:36 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CjE4j-0008Ap-MN for w3c-dist-auth@listhub.w3.org; Tue, 28 Dec 2004 09:55:33 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1CjE4j-0006mr-2C for w3c-dist-auth@w3.org; Tue, 28 Dec 2004 09:55:33 +0000 Received: from [192.168.0.3] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000071443.msg for ; Tue, 28 Dec 2004 10:54:32 +0100 In-Reply-To: <49455BF2-5851-11D9-981D-000A95B2BB72@osafoundation.org> References: <418692B6.9020207@gmx.de> <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> <41C9D8C4.6060105@gmx.de> <41CC04D3.4070701@gmx.de> <41CC4CAC.7060503@cse.ucsc.edu> <49455BF2-5851-11D9-981D-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <77A70CFA-58B6-11D9-AA55-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit Cc: Elias Sinderson , WebDAV From: Stefan Eissing Date: Tue, 28 Dec 2004 10:54:29 +0100 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Tue, 28 Dec 2004 10:54:32 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Received-SPF: none (bart.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Condition names, was: comments on draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/77A70CFA-58B6-11D9-AA55-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9222 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 28 Dec 2004 09:55:36 +0000 Content-Transfer-Encoding: 7bit Are you proposing to change RFC 3253 to get a consistent terminology? Am 27.12.2004 um 22:50 schrieb Lisa Dusseault: > > I generally agree that specification writers should re-use terminology > consistently -- great sentiment. However that isn't even what we're > talking about here. > - This isn't a case of re-using any terminology -- the issue is a set > of new error codes with a different naming style. > - We could go for a consistent style with RFC3253, however I found > the RFC3253 style confusing and prefer the quota style as-is > - The style used in the quota draft is consistent with RFC2616 style > of describing errors in text. E.g. HTTP generally describes the > error ("NOT FOUND") rather than the precondition ("RESOURCE MUST > EXIST"). > > So it's RFC3253 that made the departure in style. > > Lisa > > On Dec 24, 2004, at 9:06 AM, Elias Sinderson wrote: > >> >> Julian Reschke wrote: >> >>> I'm convinced that re-using RFC3253 terminology in an inconsistent >>> way is a Very Bad Idea [...] >> >> Reusing /any/ terminology in an inconsistent way is a bad idea -- it >> leads to confusion among implementors, makes the ensuing discussions >> overly cumbersome, etc. >> >> >> Elias >> > > From w3c-dist-auth-request@w3.org Tue Dec 28 13:00:42 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13738 for ; Tue, 28 Dec 2004 13:00:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CjLbt-0007OF-3a for w3c-dist-auth-dist@listhub.w3.org; Tue, 28 Dec 2004 17:58:17 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CjLbq-0007LQ-Ij for w3c-dist-auth@listhub.w3.org; Tue, 28 Dec 2004 17:58:14 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CjLbq-0001ww-7H for w3c-dist-auth@w3.org; Tue, 28 Dec 2004 17:58:14 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBSHw6aa017483 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 28 Dec 2004 09:58:07 -0800 In-Reply-To: <77A70CFA-58B6-11D9-AA55-00039384827E@greenbytes.de> References: <418692B6.9020207@gmx.de> <79939AA9-5451-11D9-8831-000A95AACED2@xythos.com> <41C9D8C4.6060105@gmx.de> <41CC04D3.4070701@gmx.de> <41CC4CAC.7060503@cse.ucsc.edu> <49455BF2-5851-11D9-981D-000A95B2BB72@osafoundation.org> <77A70CFA-58B6-11D9-AA55-00039384827E@greenbytes.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <00CDFD4A-58FA-11D9-981D-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Elias Sinderson , WebDAV From: Lisa Dusseault Date: Tue, 28 Dec 2004 09:57:56 -0800 To: Stefan Eissing X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Condition names, was: comments on draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/00CDFD4A-58FA-11D9-981D-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9223 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 28 Dec 2004 17:58:17 +0000 Content-Transfer-Encoding: 7bit No, I certainly don't think that changing 3253 is necessary or even desirable. Nor do I think it's necessary or desirable to block quota on this issue, no matter which way the draft has it. (and to be pedantic, it's not a consistency of terminology, it's a consistency of naming style) Lisa On Dec 28, 2004, at 1:54 AM, Stefan Eissing wrote: > Are you proposing to change RFC 3253 to get a consistent terminology? > > Am 27.12.2004 um 22:50 schrieb Lisa Dusseault: > >> >> I generally agree that specification writers should re-use >> terminology consistently -- great sentiment. However that isn't even >> what we're talking about here. >> - This isn't a case of re-using any terminology -- the issue is a >> set of new error codes with a different naming style. >> - We could go for a consistent style with RFC3253, however I found >> the RFC3253 style confusing and prefer the quota style as-is >> - The style used in the quota draft is consistent with RFC2616 style >> of describing errors in text. E.g. HTTP generally describes the >> error ("NOT FOUND") rather than the precondition ("RESOURCE MUST >> EXIST"). >> >> So it's RFC3253 that made the departure in style. >> >> Lisa >> >> On Dec 24, 2004, at 9:06 AM, Elias Sinderson wrote: >> >>> >>> Julian Reschke wrote: >>> >>>> I'm convinced that re-using RFC3253 terminology in an inconsistent >>>> way is a Very Bad Idea [...] >>> >>> Reusing /any/ terminology in an inconsistent way is a bad idea -- it >>> leads to confusion among implementors, makes the ensuing discussions >>> overly cumbersome, etc. >>> >>> >>> Elias >>> >> >> > > From w3c-dist-auth-request@w3.org Tue Dec 28 14:32:39 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19351 for ; Tue, 28 Dec 2004 14:32:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CjN3H-0005ix-2N for w3c-dist-auth-dist@listhub.w3.org; Tue, 28 Dec 2004 19:30:39 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CjN3E-0005iO-VV for w3c-dist-auth@listhub.w3.org; Tue, 28 Dec 2004 19:30:36 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CjN3E-0007eh-M1 for w3c-dist-auth@w3.org; Tue, 28 Dec 2004 19:30:36 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iBSJUVaa023594 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 28 Dec 2004 11:30:33 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200412211044.iBLAiM8w016355@ietf.cse.ucsc.edu> References: <200412211044.iBLAiM8w016355@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Tue, 28 Dec 2004 11:30:19 -0800 To: "WebDAV WG))'" X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/E88AEF42-5906-11D9-981D-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9224 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 28 Dec 2004 19:30:39 +0000 Content-Transfer-Encoding: 7bit I don't consider that this issue is resolved or fixed. Here's what I asked for in the bug text: " - when a resource with bindings A, B is locked via a LOCK request to A, what MUST the contents of the lockdiscovery property look like for both A and B? - when a resource with bindings A, B is locked via a LOCK request to A, how MUST the server respond to an UNLOCK request to B?" I would like to have requirements on the server behavior in these cases, because otherwise it will be very likely for server implementors to do slightly different things. Lisa On Dec 21, 2004, at 2:44 AM, bugzilla@soe.ucsc.edu wrote: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 > > julian.reschke@greenbytes.de changed: > > What |Removed |Added > ----------------------------------------------------------------------- > ----- > Status|REOPENED |RESOLVED > Resolution| |FIXED > > > > > > ------- You are receiving this mail because: ------- > You are the QA contact for the bug, or are watching the QA contact. > From w3c-dist-auth-request@w3.org Tue Dec 28 14:53:02 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21030 for ; Tue, 28 Dec 2004 14:53:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CjNNL-0003Ds-8v for w3c-dist-auth-dist@listhub.w3.org; Tue, 28 Dec 2004 19:51:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CjNNL-0003DO-0c for w3c-dist-auth@listhub.w3.org; Tue, 28 Dec 2004 19:51:23 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CjNNC-0001Dl-4L for w3c-dist-auth@w3.org; Tue, 28 Dec 2004 19:51:14 +0000 Received: (qmail invoked by alias); 28 Dec 2004 19:50:48 -0000 Received: from pD95357DE.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.87.222) by mail.gmx.net (mp026) with SMTP; 28 Dec 2004 20:50:48 +0100 X-Authenticated: #1915285 Message-ID: <41D1B914.9070002@gmx.de> Date: Tue, 28 Dec 2004 20:50:44 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: "WebDAV WG))'" References: <200412211044.iBLAiM8w016355@ietf.cse.ucsc.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/41D1B914.9070002@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9225 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 28 Dec 2004 19:51:23 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I don't consider that this issue is resolved or fixed. Here's what I > asked for in the bug text: > > " - when a resource with bindings A, B is locked via a LOCK request to > A, what > MUST the contents of the lockdiscovery property look like for both A > and B? > - when a resource with bindings A, B is locked via a LOCK request to > A, how > MUST the server respond to an UNLOCK request to B?" > > I would like to have requirements on the server behavior in these > cases, because otherwise it will be very likely for server implementors > to do slightly different things. The questions have been answered in : "- the value of the DAV:lockdiscovery property will be the same, as both bindings refer to the same resource, and the lock is on the resource (RFC2518, section 13.8) - UNLOCK removes the lock identified by the lock token from the resource identified by the request-URI (and all other resources included in the lock), so again, it doesn't matter to which binding the UNLOCK is applied (section 8.11)" As far as I can tell there was no working group consensus of adding LOCK semantics discussion into BIND. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Dec 28 14:59:50 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21479 for ; Tue, 28 Dec 2004 14:59:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CjNTy-0005KS-Uf for w3c-dist-auth-dist@listhub.w3.org; Tue, 28 Dec 2004 19:58:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CjNTy-0005Iu-2X; Tue, 28 Dec 2004 19:58:14 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.34) id 1CjNTp-0003SU-Bb; Tue, 28 Dec 2004 19:58:05 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iBSJve9W006575; Tue, 28 Dec 2004 14:57:40 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iBSJveNO285608; Tue, 28 Dec 2004 14:57:40 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iBSJve4M003234; Tue, 28 Dec 2004 14:57:40 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iBSJvdBB003231; Tue, 28 Dec 2004 14:57:39 -0500 In-Reply-To: To: Lisa Dusseault Cc: "WebDAV WG))'" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 28 Dec 2004 14:57:27 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/28/2004 14:57:39, Serialize complete at 12/28/2004 14:57:39 Content-Type: multipart/alternative; boundary="=_alternative 006DA45985256F78_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/OF847CE521.DD4692D4-ON85256F78.006BBEF8-85256F78.006DA45B@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9226 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 28 Dec 2004 19:58:14 +0000 This is a multipart message in MIME format. --=_alternative 006DA45985256F78_= Content-Type: text/plain; charset="US-ASCII" Lisa wrote on 12/28/2004 02:30:19 PM: > > I don't consider that this issue is resolved or fixed. Here's what I > asked for in the bug text: > > " - when a resource with bindings A, B is locked via a LOCK request to > A, what > MUST the contents of the lockdiscovery property look like for both A > and B? Whether or not a resource is mapped to multiple URL's (via bindings or any other mechanism) has no effect on the lockdiscovery property. So the lockdiscovery property is exactly what the locking protocol says it will be when that resource is mapped to a single URL. Since the binding protocol does not modify the definition of the lockdiscovery property, I would object to it restating that definition, especially since that definition may be revised in 2518bis. > - when a resource with bindings A, B is locked via a LOCK request to > A, how > MUST the server respond to an UNLOCK request to B?" That depends on how this question is resolved in RFC2518bis (or preferably, in a separate locking protocol document split off from 2518bis). If an UNLOCK must be applied to the URL to which the original LOCK request was applied, then it must be unlocked via an UNLOCK to A. If an UNLOCK can be applied to any URL that identifies a resource that is locked by that lock, then it can be applied to B. This is the same question that arises in the context of a depth lock, and the answer should be consistent. As I recall, the last time this was discussed, the group was leaning towards the latter (i.e. that the UNLOCK can be applied to any URL that identifies a resource locked by the lock), but this is a question that should/must be resolved by the locking protocol, not be the binding protocol, if we want consistent behavior defined. > I would like to have requirements on the server behavior in these > cases, because otherwise it will be very likely for server implementors > to do slightly different things. I would also like to have locking behavior defined, which is why I continue to advocate splitting off the locking protocol from 2518bis for rapid action. But putting a couple of bits of information about the locking protocol in the binding protocol that have a 50/50 chance of conflicting with how the semantics are defined in the locking protocol makes no sense at all. So I completely agree with Julian's marking this issue as resolved. Cheers, Geoff > > Lisa > > On Dec 21, 2004, at 2:44 AM, bugzilla@soe.ucsc.edu wrote: > > > > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 > > > > julian.reschke@greenbytes.de changed: > > > > What |Removed |Added > > ----------------------------------------------------------------------- > > ----- > > Status|REOPENED |RESOLVED > > Resolution| |FIXED > > > > > > > > > > > > ------- You are receiving this mail because: ------- > > You are the QA contact for the bug, or are watching the QA contact. > > > > --=_alternative 006DA45985256F78_= Content-Type: text/html; charset="US-ASCII"
Lisa wrote on 12/28/2004 02:30:19 PM:
>
> I don't consider that this issue is resolved or fixed.  Here's what I  
> asked for in the bug text:
>
> " - when a resource with bindings A, B is locked via a LOCK request to  
> A, what
> MUST the contents of the lockdiscovery property look like for both A  
> and B?

Whether or not a resource is mapped to multiple URL's (via bindings or
any other mechanism) has no effect on the lockdiscovery property.
So the lockdiscovery property is exactly what the locking protocol says
it will be when that resource is mapped to a single URL.

Since the binding protocol does not modify the definition of the
lockdiscovery property, I would object to it restating that definition,
especially since that definition may be revised in 2518bis.

>   - when a resource with bindings A, B is locked via a LOCK request to  
> A, how
> MUST the server respond to an UNLOCK request to B?"

That depends on how this question is resolved in RFC2518bis
(or preferably, in a separate locking protocol document split off from 2518bis).
If an UNLOCK must be applied to the URL to which the original LOCK
request was applied, then it must be unlocked via an UNLOCK to A.
If an UNLOCK can be applied to any URL that identifies a resource
that is locked by that lock, then it can be applied to B.
This is the same question that arises in the context of a depth
lock, and the answer should be consistent.  As I recall, the last time
this was discussed, the group was leaning towards the latter (i.e. that
the UNLOCK can be applied to any URL that identifies a resource locked
by the lock), but this is a question that should/must be resolved by the
locking protocol, not be the binding protocol, if we want consistent
behavior defined.

> I would like to have requirements on the server behavior in these  
> cases, because otherwise it will be very likely for server implementors  
> to do slightly different things.

I would also like to have locking behavior defined, which is why I continue
to advocate splitting off the locking protocol from 2518bis for rapid
action.  But putting a couple of bits of information about the locking
protocol in the binding protocol that have a 50/50 chance of conflicting
with how the semantics are defined in the locking protocol makes no sense at all.

So I completely agree with Julian's marking this issue as resolved.

Cheers,
Geoff


>
> Lisa
>
> On Dec 21, 2004, at 2:44 AM, bugzilla@soe.ucsc.edu wrote:
>
> >
> > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2
> >
> > julian.reschke@greenbytes.de changed:
> >
> >            What    |Removed                     |Added
> > -----------------------------------------------------------------------
> > -----
> >              Status|REOPENED                    |RESOLVED
> >          Resolution|                            |FIXED
> >
> >
> >
> >
> >
> > ------- You are receiving this mail because: -------
> > You are the QA contact for the bug, or are watching the QA contact.
> >
>
>
--=_alternative 006DA45985256F78_=-- From w3c-dist-auth-request@w3.org Tue Dec 28 15:18:11 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23140 for ; Tue, 28 Dec 2004 15:18:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CjNkT-0000nj-FK for w3c-dist-auth-dist@listhub.w3.org; Tue, 28 Dec 2004 20:15:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CjNkO-0000mm-Qc for w3c-dist-auth@listhub.w3.org; Tue, 28 Dec 2004 20:15:12 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CjNkF-00087j-Qy for w3c-dist-auth@w3.org; Tue, 28 Dec 2004 20:15:04 +0000 Received: (qmail invoked by alias); 28 Dec 2004 20:14:39 -0000 Received: from pD95357DE.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.87.222) by mail.gmx.net (mp016) with SMTP; 28 Dec 2004 21:14:39 +0100 X-Authenticated: #1915285 Message-ID: <41D1BEA9.30100@gmx.de> Date: Tue, 28 Dec 2004 21:14:33 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: Lisa Dusseault , "WebDAV WG))'" , w3c-dist-auth-request@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/41D1BEA9.30100@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9227 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 28 Dec 2004 20:15:17 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > ... > I would also like to have locking behavior defined, which is why I continue > to advocate splitting off the locking protocol from 2518bis for rapid > action. But putting a couple of bits of information about the locking > protocol in the binding protocol that have a 50/50 chance of conflicting > with how the semantics are defined in the locking protocol makes no > sense at all. > ... ...speaking of which, what *is* the status of RFC2518bis? It was on the IETF meeting's agenda, but for some reason it doesn't seem that it was discussed there. Unless there are concrete plans to actually work on it (and the issues raised on the mailing list and now collected at ), I'd propose to actually take out the locking part (as repeatedly proposed in the past 12 months) and continue work on . This would significantly reduce the complexity of the base protocol (see experimental edit at , and thus make it much easier to progress to Draft standard). Best regards, Julian P.S.: last mention of RFC2518bis on the mailing list seems to be in : > While I appreciate all the issues reported with RFC2518, I am not > dealing with them until we have issue status tracking more firmly in > hand somehow. Joe is investigating tools to help with this issue. > > Thanks, > Lisa -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760