From w3c-dist-auth-request@w3.org Wed Sep 1 11:55: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 LAA02137 for ; Wed, 1 Sep 2004 11:55:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C2PLk-0007hs-MV; Wed, 01 Sep 2004 07:16:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C2PLk-0007hM-58 for w3c-dist-auth@listhub.w3.org; Wed, 01 Sep 2004 07:16:08 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C2PLj-0002QR-B4 for w3c-dist-auth@w3.org; Wed, 01 Sep 2004 07:16:07 +0000 Received: (qmail 30454 invoked by uid 65534); 1 Sep 2004 07:15:33 -0000 Received: from pD9535902.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.89.2) by mail.gmx.net (mp003) with SMTP; 01 Sep 2004 09:15:33 +0200 X-Authenticated: #1915285 Message-ID: <41357711.1080309@gmx.de> Date: Wed, 01 Sep 2004 09:15:29 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/41357711.1080309@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8771 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 Sep 2004 07:16:08 +0000 Content-Transfer-Encoding: 7bit Hi, I just submitted draft 07 of draft-reschke-webdav-property-datatypes: As previously announced, this draft removes the definition of various property flags and DASL extensions, concentrating on the core property datatyping as implemented / being implemented in SAP's Enterprise Portal and SAP Netweaver, and Xythos WebFile Server. This part of the spec has been stable for several years now, and as far as I can tell, the WebDAV working group currently lacks the time to transform this into a Working Group activity. On the other hand, this work not only is implemented in shipping products, it should also be valuable for anybody looking at adding typing to WebDAV properties. Thus, it probably makes sense for it being published by the IETF, either as experimental or proposed protocol. I hereby invite all readers to review the spec (both for content and editorial aspects). Unless no new issues are raised, I plan to last-call it and then submit it to the IESG as a private submission. I'd also appreciate feedback on which publication status (experimental/proposed) I should target. Note that those sections that were removed (see change information in ) will later appear in a separate draft built on top of the core property types spec. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 2 14:51: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 OAA27357 for ; Thu, 2 Sep 2004 14:51:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C2wdd-0006nv-Ht; Thu, 02 Sep 2004 18:48:49 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C2wdd-0006nK-0q for w3c-dist-auth@listhub.w3.org; Thu, 02 Sep 2004 18:48:49 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1C2wdc-0004tj-Nq for w3c-dist-auth@w3.org; Thu, 02 Sep 2004 18:48:48 +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 i82ImYpp022498 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 2 Sep 2004 11:48:35 -0700 In-Reply-To: References: <200407192004.QAA19839@ietf.org> <4130C4C0.7020609@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: Julian Reschke , w3c-dist-auth@w3.org From: Lisa Dusseault Date: Thu, 2 Sep 2004 11:48:26 -0700 To: Brian Korver X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (bart.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/AC992236-FD10-11D8-BF77-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8772 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 Sep 2004 18:48:49 +0000 Content-Transfer-Encoding: 7bit >> >> 02-C01 Condition Name >> >> Use name of precondition, not failure description: >> instead of > > Unless anyone objects, I'll make that change. > I do object (but not to the point of delaying quota). My reasoning is that using the negative, to express the condition that must be met, is hard to understand for the debugger/implementor/tester or support person. You see something like this: and think "Huh? My error is that quota is not exceeded? what's up with that? " I can even imagine bugs logged against implementors who correctly follow the spec. Furthermore, although this approach is consistent with the style in DeltaV, it's not consistent with the overall HTTP error style, which is to explain the error. E.g. "404 Not Found" rather than "404 Document Must Exist". Lisa From w3c-dist-auth-request@w3.org Thu Sep 2 14:52: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 OAA27412 for ; Thu, 2 Sep 2004 14:52:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C2wfS-0007kz-Gp; Thu, 02 Sep 2004 18:50:42 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C2wfS-0007kT-A3 for w3c-dist-auth@listhub.w3.org; Thu, 02 Sep 2004 18:50:42 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C2wfR-00054B-UZ for w3c-dist-auth@w3.org; Thu, 02 Sep 2004 18:50:42 +0000 Received: (qmail 2337 invoked by uid 65534); 2 Sep 2004 18:50:08 -0000 Received: from p54856C66.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.108.102) by mail.gmx.net (mp026) with SMTP; 02 Sep 2004 20:50:08 +0200 X-Authenticated: #1915285 Message-ID: <41376B5B.7020003@gmx.de> Date: Thu, 02 Sep 2004 20:50:03 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: w3c-dist-auth@w3.org References: <200407192004.QAA19839@ietf.org> <4130C4C0.7020609@gmx.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/41376B5B.7020003@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8773 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 Sep 2004 18:50:42 +0000 Content-Transfer-Encoding: 7bit Thanks for the feedback, Brian. Comments follow inline. Brian Korver wrote: >> 01-C02 (third property) >> >> >> >> The issue here seems to be that an additional property is required to >> make the quota authorable. I honestly haven't understood yet why it's >> needed. The problem seems to be that as the reported quota may be a >> "best pick" by the server (there may be multiple quotas in place, but >> only the most strict will be reported at any point of time). If this >> is the case this could potentially be fixed by exposing all quotas to >> the client. >> >> At the end of the day, unless we can agree about how this is supposed >> to work I strongly suggest to leave it out of the base spec and use a >> vendor-specific property for setting it. > > > A while back I asked those who objected to the specifics > of the authorable quota functionality to propose > alternative methods of obtaining that functionality, > which no one responded to until your proposal here. (it's the same proposal I made last autumn) > That's a reasonable idea if no vendors plan to support > authorable quotas in an interoperable manner, which > may be true. So let me ask this of the list: if you > do (or are possibly planning to) support quotas in your > server implementation, will you never be making those > quotas authorable and hence have no need for this > as an optional feature of the quota spec? I know > Xythos would like to do this in an non-proprietary > (interoperable) manner. It's good that you ask; and I'm interested to find out what people think. If we don't need this right now we can vastly simplify the spec. On the other hand, if people want it, someone needs to figure out how this is going to work in a predictable manner. >> 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) > > > When this was discussed in the past (for instance in SC) > the general consensus was that clients want a single number > to display. If you want to revisit that issue and by proposing > another property be added, perhaps a good place to start would > be to provide the text to the list for discussion. If people are interested to send information about physical storage limits, I'll be happy to make a proposal. The main point being that quotas and physical storage limits are *not* the same thing; and throwing them together potentially causes confusion, in particular if you want to make the quota part authorable (see older messages). Therefore I'd favor a separate document describing that property. > I think a necessary part of that text should be to discuss > how a client should decide which number to display when both > properties are returned. However, how many implementations Display both, or the smaller one? > will return both? AFAIK, the two implementations of the quota > property (ours and Apple's) will only return one of the > properties (or possibly both set to exactly the same thing) > since there's no real semantic difference between the two. There is, for instance when mapping HTTP status codes (which should be distinguishable) to OS error codes (for instance, Unix has different errnos to map to). > ... >> 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. >> >> >> >> Unfortunately, neither was the discussion was finished nor do I see a >> change in the spec. > > > Right, no one explained how to use "quota space" to simplify the > spec (especially given we just copy-and-pasted the property > description text from the NFS spec) or provided the requested > replacement text. Well, nobody likes to do heavy editorial work unless there's a chance it'll get used. If we agree that it makes sense to use that terminology, and to base the remainder of the spec on these definitions, then I'll gladly make a proposal. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 2 14:59: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 OAA27803 for ; Thu, 2 Sep 2004 14:59:12 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C2wmM-0001Zv-RL; Thu, 02 Sep 2004 18:57:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C2wmM-0001ZK-F3 for w3c-dist-auth@listhub.w3.org; Thu, 02 Sep 2004 18:57:50 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C2wmL-0002eA-Id for w3c-dist-auth@w3.org; Thu, 02 Sep 2004 18:57:49 +0000 Received: (qmail 12434 invoked by uid 65534); 2 Sep 2004 18:57:17 -0000 Received: from p54856C66.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.108.102) by mail.gmx.net (mp003) with SMTP; 02 Sep 2004 20:57:17 +0200 X-Authenticated: #1915285 Message-ID: <41376D08.30301@gmx.de> Date: Thu, 02 Sep 2004 20:57:12 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Brian Korver , w3c-dist-auth@w3.org References: <200407192004.QAA19839@ietf.org> <4130C4C0.7020609@gmx.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/41376D08.30301@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8774 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 Sep 2004 18:57:50 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I do object (but not to the point of delaying quota). My reasoning is > that using the negative, to express the condition that must be met, is > hard to understand for the debugger/implementor/tester or support > person. You see something like this: > > > > > > and think "Huh? My error is that quota is not exceeded? what's up with > that? " I can even imagine bugs logged against implementors who > correctly follow the spec. On the other hand, implementors may be accustomed with the terminology used by RFC3253, RFC3648 and RFC3744, and become confused by a new spec being inconsistent with it. Also, people seeing DAV:error (and not already familiar with RFC3253) will hopefully find the specification, which will point them to RFC3253, section 1.6, which explains it all. If server implementors want to make it super-readable, they can still add additional programmer-readable prose inside an XML comment in the response body. > Furthermore, although this approach is consistent with the style in > DeltaV, it's not consistent with the overall HTTP error style, which is > to explain the error. E.g. "404 Not Found" rather than "404 Document > Must Exist". That's true, but I don't think it matters today. This is what RFC3253 defines, and unless there's a *really* good reason to be inconsistent with that, we should stick with it. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 2 16:14: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 QAA03469 for ; Thu, 2 Sep 2004 16:14:32 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C2xwf-00026W-7L; Thu, 02 Sep 2004 20:12:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C2xwe-000260-Kc for w3c-dist-auth@listhub.w3.org; Thu, 02 Sep 2004 20:12:32 +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 1C2xwd-0005QZ-Ou for w3c-dist-auth@w3.org; Thu, 02 Sep 2004 20:12:31 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Sep 2004 13:11:56 -0700 In-Reply-To: <41376B5B.7020003@gmx.de> References: <200407192004.QAA19839@ietf.org> <4130C4C0.7020609@gmx.de> <41376B5B.7020003@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <56B66318-FD1C-11D8-A93D-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Brian Korver Date: Thu, 2 Sep 2004 13:11:56 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 02 Sep 2004 20:11:56.0290 (UTC) FILETIME=[18700E20:01C49129] 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: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/56B66318-FD1C-11D8-A93D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8775 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 Sep 2004 20:12:33 +0000 Content-Transfer-Encoding: 7bit On Sep 2, 2004, at 11:50 AM, Julian Reschke wrote: > Thanks for the feedback, Brian. Comments follow inline. > > > Brian Korver wrote: > >>> 01-C02 (third property) >>> >> 0425.html> >>> >> 0436.html> >>> >>> The issue here seems to be that an additional property is required >>> to make the quota authorable. I honestly haven't understood yet why >>> it's needed. The problem seems to be that as the reported quota may >>> be a "best pick" by the server (there may be multiple quotas in >>> place, but only the most strict will be reported at any point of >>> time). If this is the case this could potentially be fixed by >>> exposing all quotas to the client. >>> >>> At the end of the day, unless we can agree about how this is >>> supposed to work I strongly suggest to leave it out of the base >>> spec and use a vendor-specific property for setting it. >> A while back I asked those who objected to the specifics >> of the authorable quota functionality to propose >> alternative methods of obtaining that functionality, >> which no one responded to until your proposal here. > > (it's the same proposal I made last autumn) > >> That's a reasonable idea if no vendors plan to support >> authorable quotas in an interoperable manner, which >> may be true. So let me ask this of the list: if you >> do (or are possibly planning to) support quotas in your >> server implementation, will you never be making those >> quotas authorable and hence have no need for this >> as an optional feature of the quota spec? I know >> Xythos would like to do this in an non-proprietary >> (interoperable) manner. > > It's good that you ask; and I'm interested to find out what people > think. If we don't need this right now we can vastly simplify the > spec. On the other hand, if people want it, someone needs to figure > out how this is going to work in a predictable manner. It's a single value. > >>> 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) >> When this was discussed in the past (for instance in SC) >> the general consensus was that clients want a single number >> to display. If you want to revisit that issue and by proposing >> another property be added, perhaps a good place to start would >> be to provide the text to the list for discussion. > > If people are interested to send information about physical storage > limits, I'll be happy to make a proposal. The main point being that > quotas and physical storage limits are *not* the same thing; and > throwing them together potentially causes confusion, in particular if > you want to make the quota part authorable (see older messages). > Therefore I'd favor a separate document describing that property. > >> I think a necessary part of that text should be to discuss >> how a client should decide which number to display when both >> properties are returned. However, how many implementations > > Display both, or the smaller one? Right. > >> will return both? AFAIK, the two implementations of the quota >> property (ours and Apple's) will only return one of the >> properties (or possibly both set to exactly the same thing) >> since there's no real semantic difference between the two. > > There is, for instance when mapping HTTP status codes (which should be > distinguishable) to OS error codes (for instance, Unix has different > errnos to map to). You lost me here. I'm not sure what you're referring to. > >> ... >>> 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. >> Right, no one explained how to use "quota space" to simplify the >> spec (especially given we just copy-and-pasted the property >> description text from the NFS spec) or provided the requested >> replacement text. > > Well, nobody likes to do heavy editorial work unless there's a chance > it'll get used. If we agree that it makes sense to use that > terminology, and to base the remainder of the spec on these > definitions, then I'll gladly make a proposal. > > > ... > > Best regards, Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Thu Sep 2 16:23: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 QAA04778 for ; Thu, 2 Sep 2004 16:23:01 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C2y5T-0004dw-Tq; Thu, 02 Sep 2004 20:21:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C2y5S-0004dQ-5R for w3c-dist-auth@listhub.w3.org; Thu, 02 Sep 2004 20:21:38 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C2y5R-0006ov-7J for w3c-dist-auth@w3.org; Thu, 02 Sep 2004 20:21:37 +0000 Received: (qmail 21099 invoked by uid 65534); 2 Sep 2004 20:21:05 -0000 Received: from p54856C66.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.108.102) by mail.gmx.net (mp021) with SMTP; 02 Sep 2004 22:21:05 +0200 X-Authenticated: #1915285 Message-ID: <413780AE.5000605@gmx.de> Date: Thu, 02 Sep 2004 22:21:02 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: w3c-dist-auth@w3.org References: <200407192004.QAA19839@ietf.org> <4130C4C0.7020609@gmx.de> <41376B5B.7020003@gmx.de> <56B66318-FD1C-11D8-A93D-000A95AACED2@xythos.com> In-Reply-To: <56B66318-FD1C-11D8-A93D-000A95AACED2@xythos.com> Content-Type: text/plain; charset=us-ascii; 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: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/413780AE.5000605@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8776 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 Sep 2004 20:21:39 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: >> It's good that you ask; and I'm interested to find out what people >> think. If we don't need this right now we can vastly simplify the >> spec. On the other hand, if people want it, someone needs to figure >> out how this is going to work in a predictable manner. > > It's a single value. That's not an answer. If you have a "display" property and an authorable property, and the former may return information depending on what's most "relevant" at a given point of time, clients will have a hard time to predictably change that property. >> There is, for instance when mapping HTTP status codes (which should be >> distinguishable) to OS error codes (for instance, Unix has different >> errnos to map to). > > > You lost me here. I'm not sure what you're referring to. For instance, MacOSX maps HTTP status codes to Unix error codes (it's a filesystem mapper). Unix distinguishes between "no space left on device" and "quota exceeded". The protocol should allow the client to distinguish both cases. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 2 17:40: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 RAA14107 for ; Thu, 2 Sep 2004 17:40:17 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C2zI9-0006Rl-NM; Thu, 02 Sep 2004 21:38:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C2zI4-0006MA-Kv for w3c-dist-auth@listhub.w3.org; Thu, 02 Sep 2004 21:38:44 +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 1C2zI3-0002pg-Pr for w3c-dist-auth@w3.org; Thu, 02 Sep 2004 21:38: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, 2 Sep 2004 14:38:10 -0700 In-Reply-To: <413780AE.5000605@gmx.de> References: <200407192004.QAA19839@ietf.org> <4130C4C0.7020609@gmx.de> <41376B5B.7020003@gmx.de> <56B66318-FD1C-11D8-A93D-000A95AACED2@xythos.com> <413780AE.5000605@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <637984DA-FD28-11D8-A93D-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Brian Korver Date: Thu, 2 Sep 2004 14:38:11 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 02 Sep 2004 21:38:10.0832 (UTC) FILETIME=[24B48100:01C49135] 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: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/637984DA-FD28-11D8-A93D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8777 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 Sep 2004 21:38:49 +0000 Content-Transfer-Encoding: 7bit On Sep 2, 2004, at 1:21 PM, Julian Reschke wrote: > Brian Korver wrote: > >>> It's good that you ask; and I'm interested to find out what people >>> think. If we don't need this right now we can vastly simplify the >>> spec. On the other hand, if people want it, someone needs to figure >>> out how this is going to work in a predictable manner. >> It's a single value. > > That's not an answer. If you have a "display" property and an > authorable property, and the former may return information depending > on what's most "relevant" at a given point of time, clients will have > a hard time to predictably change that property. There seems to be a misunderstanding (due to underspecification?). The value of DAV:quota-assigned-bytes is intended to be deterministic. I guess that needs to be spelled out explicitly in the spec. > >>> There is, for instance when mapping HTTP status codes (which should >>> be distinguishable) to OS error codes (for instance, Unix has >>> different errnos to map to). >> You lost me here. I'm not sure what you're referring to. > > For instance, MacOSX maps HTTP status codes to Unix error codes (it's > a filesystem mapper). Unix distinguishes between "no space left on > device" and "quota exceeded". The protocol should allow the client to > distinguish both cases. Since the only two implementations of the quota property that I know of don't make this distinction, I think it's difficult to argue for adding this requirement. > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Thu Sep 2 17:54: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 RAA15032 for ; Thu, 2 Sep 2004 17:54:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C2zVP-00046W-Sk; Thu, 02 Sep 2004 21:52:31 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C2zVP-00045u-37 for w3c-dist-auth@listhub.w3.org; Thu, 02 Sep 2004 21:52:31 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1C2zVO-0002Qy-Pi for w3c-dist-auth@w3.org; Thu, 02 Sep 2004 21:52:30 +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 i82LqCpp000997 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 2 Sep 2004 14:52:12 -0700 In-Reply-To: <413780AE.5000605@gmx.de> References: <200407192004.QAA19839@ietf.org> <4130C4C0.7020609@gmx.de> <41376B5B.7020003@gmx.de> <56B66318-FD1C-11D8-A93D-000A95AACED2@xythos.com> <413780AE.5000605@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <53F67CC4-FD2A-11D8-BF77-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org, Brian Korver From: Lisa Dusseault Date: Thu, 2 Sep 2004 14:52:04 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (bart.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/53F67CC4-FD2A-11D8-BF77-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8778 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 Sep 2004 21:52:31 +0000 Content-Transfer-Encoding: 7bit On Sep 2, 2004, at 1:21 PM, Julian Reschke wrote: > > For instance, MacOSX maps HTTP status codes to Unix error codes (it's > a filesystem mapper). Unix distinguishes between "no space left on > device" and "quota exceeded". The protocol should allow the client to > distinguish both cases. I disagree. The chances that a single system has both apply in a meaningful way, and that the client needs to do both, and that the client has a way to display both, are pretty small. The same mechanism can handle either case but not both at once. Lisa From w3c-dist-auth-request@w3.org Fri Sep 3 03:22: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 DAA03799 for ; Fri, 3 Sep 2004 03:22:55 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C38NN-0001Pk-T0; Fri, 03 Sep 2004 07:20:49 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C38NN-0001PE-8S for w3c-dist-auth@listhub.w3.org; Fri, 03 Sep 2004 07:20:49 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C38NM-000351-Rb for w3c-dist-auth@w3.org; Fri, 03 Sep 2004 07:20:49 +0000 Received: (qmail 7183 invoked by uid 65534); 3 Sep 2004 07:20:16 -0000 Received: from p54856BE7.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.107.231) by mail.gmx.net (mp023) with SMTP; 03 Sep 2004 09:20:16 +0200 X-Authenticated: #1915285 Message-ID: <41381B28.1080400@gmx.de> Date: Fri, 03 Sep 2004 09:20:08 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: w3c-dist-auth@w3.org References: <200407192004.QAA19839@ietf.org> <4130C4C0.7020609@gmx.de> <41376B5B.7020003@gmx.de> <56B66318-FD1C-11D8-A93D-000A95AACED2@xythos.com> <413780AE.5000605@gmx.de> <637984DA-FD28-11D8-A93D-000A95AACED2@xythos.com> In-Reply-To: <637984DA-FD28-11D8-A93D-000A95AACED2@xythos.com> Content-Type: text/plain; charset=us-ascii; 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: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/41381B28.1080400@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8779 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 Sep 2004 07:20:49 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > There seems to be a misunderstanding (due to underspecification?). > The value of DAV:quota-assigned-bytes is intended to be deterministic. > I guess that needs to be spelled out explicitly in the spec. So what's the relation between DAV:quota-assigned-bytes and DAV:quota-used-bytes? > Since the only two implementations of the quota property > that I know of don't make this distinction, I think it's > difficult to argue for adding this requirement. How are they supposed to make that distinction when they currently can't? Anyway: if you want to write down what two specific implementations do, then produce a non-WG track document, and try to publish through the IETF (or elsewhere). If this is supposed to be a WG activity, you'll also have to listen to those that do not currently implement it, but might want to do so in the future. If there's a split between things we have consensus on and extensions, and the former part is useful on it's own, put *that* in the standard tracks document and put the rest into an extension. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Sep 3 03:25: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 DAA03956 for ; Fri, 3 Sep 2004 03:25:17 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C38QF-0002Ul-Kd; Fri, 03 Sep 2004 07:23:47 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C38QF-0002UF-8B for w3c-dist-auth@listhub.w3.org; Fri, 03 Sep 2004 07:23:47 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C38QE-0003oG-RN for w3c-dist-auth@w3.org; Fri, 03 Sep 2004 07:23:47 +0000 Received: (qmail 5056 invoked by uid 65534); 3 Sep 2004 07:23:15 -0000 Received: from p54856BE7.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.107.231) by mail.gmx.net (mp001) with SMTP; 03 Sep 2004 09:23:15 +0200 X-Authenticated: #1915285 Message-ID: <41381BDF.1050700@gmx.de> Date: Fri, 03 Sep 2004 09:23:11 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: w3c-dist-auth@w3.org, Brian Korver References: <200407192004.QAA19839@ietf.org> <4130C4C0.7020609@gmx.de> <41376B5B.7020003@gmx.de> <56B66318-FD1C-11D8-A93D-000A95AACED2@xythos.com> <413780AE.5000605@gmx.de> <53F67CC4-FD2A-11D8-BF77-000A95B2BB72@osafoundation.org> In-Reply-To: <53F67CC4-FD2A-11D8-BF77-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=us-ascii; 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: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/41381BDF.1050700@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8780 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 Sep 2004 07:23:47 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > On Sep 2, 2004, at 1:21 PM, Julian Reschke wrote: > >> >> For instance, MacOSX maps HTTP status codes to Unix error codes (it's >> a filesystem mapper). Unix distinguishes between "no space left on >> device" and "quota exceeded". The protocol should allow the client to >> distinguish both cases. > > > I disagree. The chances that a single system has both apply in a > meaningful way, and that the client needs to do both, and that the > client has a way to display both, are pretty small. The same mechanism > can handle either case but not both at once. Correct. So are you saying that (i) a system can't have both quotas and disk limits or (ii) that we should have two different mechanisms? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Sep 3 05:28: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 FAA10407 for ; Fri, 3 Sep 2004 05:28:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C3AL2-0006xM-45; Fri, 03 Sep 2004 09:26:32 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C3AL1-0006wU-He for w3c-dist-auth@listhub.w3.org; Fri, 03 Sep 2004 09:26:31 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C3AL1-0005mK-4V for w3c-dist-auth@w3.org; Fri, 03 Sep 2004 09:26:31 +0000 Received: (qmail 27249 invoked by uid 65534); 3 Sep 2004 09:25:59 -0000 Received: from p50824F12.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.79.18) by mail.gmx.net (mp023) with SMTP; 03 Sep 2004 11:25:59 +0200 X-Authenticated: #1915285 Message-ID: <413838A5.6070203@gmx.de> Date: Fri, 03 Sep 2004 11:25:57 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/413838A5.6070203@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8781 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 Sep 2004 09:26:32 +0000 Content-Transfer-Encoding: 7bit OK, here's another question about DAV:quota-assigned-bytes...: Let's assume a quota system that works as the one in Unix and/or Windows NT, that is - quota can be enabled/disabled per physical file system, - quota is counted per user across all files on that file system. Consider a server that has a lot of users for who quotas are set up. Most of these users will not have the permission to change their quota on their own. On the other hand, users with admin privileges are authorized to change quota for other users, however there doesn't seem to be a way for them to use DAV:quota-assigned-bytes for it (as this property will vary by authenticated user, not the request URI). To summarize, the property as currently described seems to work only for those cases where quota is maintained by folder, not by user and doesn't seem to usable for other systems. Thus, the whole concept of "authorable" quota should be either removed from the spec, or it needs to be rewritten in a way so that it works for other scenarios as well. (my preference being to leave it out unless there are volunteers who want to work on this issue). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Sep 3 12:24: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 MAA08940 for ; Fri, 3 Sep 2004 12:24:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C3GpT-0001vk-2l; Fri, 03 Sep 2004 16:22:23 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C3GpS-0001r7-GI for w3c-dist-auth@listhub.w3.org; Fri, 03 Sep 2004 16:22:22 +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 1C3GpS-0001Yk-82 for w3c-dist-auth@w3.org; Fri, 03 Sep 2004 16:22:22 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Sep 2004 09:21:50 -0700 In-Reply-To: <413838A5.6070203@gmx.de> References: <413838A5.6070203@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5B3B84A2-FDC5-11D8-A93D-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Brian Korver Date: Fri, 3 Sep 2004 09:21:48 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 03 Sep 2004 16:21:50.0692 (UTC) FILETIME=[1E12BA40:01C491D2] 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/5B3B84A2-FDC5-11D8-A93D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8782 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 Sep 2004 16:22:23 +0000 Content-Transfer-Encoding: 7bit Anyone who is going to support this use case should speak up because if no one wants to support your proposed use case then the issue is moot. -brian briank@xythos.com On Sep 3, 2004, at 2:25 AM, Julian Reschke wrote: > OK, > > here's another question about DAV:quota-assigned-bytes...: > > Let's assume a quota system that works as the one in Unix and/or > Windows NT, that is > > - quota can be enabled/disabled per physical file system, > - quota is counted per user across all files on that file system. > > Consider a server that has a lot of users for who quotas are set up. > Most of these users will not have the permission to change their quota > on their own. > > On the other hand, users with admin privileges are authorized to > change quota for other users, however there doesn't seem to be a way > for them to use DAV:quota-assigned-bytes for it (as this property will > vary by authenticated user, not the request URI). > > To summarize, the property as currently described seems to work only > for those cases where quota is maintained by folder, not by user and > doesn't seem to usable for other systems. > > Thus, the whole concept of "authorable" quota should be either removed > from the spec, or it needs to be rewritten in a way so that it works > for other scenarios as well. (my preference being to leave it out > unless there are volunteers who want to work on this issue). > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Fri Sep 3 12:41: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 MAA10152 for ; Fri, 3 Sep 2004 12:41:27 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C3H6W-0006lo-F9; Fri, 03 Sep 2004 16:40:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C3H6V-0006lF-Vx for w3c-dist-auth@listhub.w3.org; Fri, 03 Sep 2004 16:39:59 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1C3H6U-0005eK-W4 for w3c-dist-auth@w3.org; Fri, 03 Sep 2004 16:39:59 +0000 Received: (qmail 22308 invoked by uid 65534); 3 Sep 2004 16:39:26 -0000 Received: from p50824F12.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.79.18) by mail.gmx.net (mp025) with SMTP; 03 Sep 2004 18:39:26 +0200 X-Authenticated: #1915285 Message-ID: <41389E3D.2090204@gmx.de> Date: Fri, 03 Sep 2004 18:39:25 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: w3c-dist-auth@w3.org References: <413838A5.6070203@gmx.de> <5B3B84A2-FDC5-11D8-A93D-000A95AACED2@xythos.com> In-Reply-To: <5B3B84A2-FDC5-11D8-A93D-000A95AACED2@xythos.com> Content-Type: text/plain; charset=us-ascii; 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/41389E3D.2090204@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8783 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 Sep 2004 16:40:00 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > Anyone who is going to support this use case should speak up > because if no one wants to support your proposed use case then > the issue is moot. So you're saying that the fact that the protocol as specified is incompatible with both the NTFS and Unix quota model is moot? As far as I can tell, the spec as currently published is optimized for one very specific implementation. That's fine, unless people want to make it *the* quota protocol with backing of the WebDAV working group. Please either simplify the protocol in a way so that other implementations become possible (moving too specific features into private extensions), or publish what you have as Informational RFC describing what one specific system is supporting today. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Sep 3 13:09: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 NAA11500 for ; Fri, 3 Sep 2004 13:09:53 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C3HXy-00070p-2X; Fri, 03 Sep 2004 17:08:22 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C3HXx-000706-MQ for w3c-dist-auth@listhub.w3.org; Fri, 03 Sep 2004 17:08:21 +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 1C3HXx-0000Oo-EO for w3c-dist-auth@w3.org; Fri, 03 Sep 2004 17:08:21 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Sep 2004 10:07:50 -0700 In-Reply-To: <41381B28.1080400@gmx.de> References: <200407192004.QAA19839@ietf.org> <4130C4C0.7020609@gmx.de> <41376B5B.7020003@gmx.de> <56B66318-FD1C-11D8-A93D-000A95AACED2@xythos.com> <413780AE.5000605@gmx.de> <637984DA-FD28-11D8-A93D-000A95AACED2@xythos.com> <41381B28.1080400@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Brian Korver Date: Fri, 3 Sep 2004 10:07:48 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 03 Sep 2004 17:07:50.0425 (UTC) FILETIME=[8B009090:01C491D8] 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: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/C84DDE62-FDCB-11D8-A93D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8784 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 Sep 2004 17:08:22 +0000 Content-Transfer-Encoding: 7bit On Sep 3, 2004, at 12:20 AM, Julian Reschke wrote: > Brian Korver wrote: > >> There seems to be a misunderstanding (due to underspecification?). >> The value of DAV:quota-assigned-bytes is intended to be deterministic. >> I guess that needs to be spelled out explicitly in the spec. > > So what's the relation between DAV:quota-assigned-bytes and > DAV:quota-used-bytes? Quite possibly none. > >> Since the only two implementations of the quota property >> that I know of don't make this distinction, I think it's >> difficult to argue for adding this requirement. > > How are they supposed to make that distinction when they currently > can't? > > Anyway: if you want to write down what two specific implementations > do, then produce a non-WG track document, and try to publish through > the IETF (or elsewhere). If this is supposed to be a WG activity, > you'll also have to listen to those that do not currently implement > it, but might want to do so in the future. > > If there's a split between things we have consensus on and extensions, > and the former part is useful on it's own, put *that* in the standard > tracks document and put the rest into an extension. > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Sep 3 13:10: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 NAA11539 for ; Fri, 3 Sep 2004 13:10:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C3HZ3-0007V1-IQ; Fri, 03 Sep 2004 17:09:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C3HZ3-0007UV-8K for w3c-dist-auth@listhub.w3.org; Fri, 03 Sep 2004 17:09:29 +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 1C3HZ2-0001Ay-Do for w3c-dist-auth@w3.org; Fri, 03 Sep 2004 17:09:28 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Sep 2004 10:08:57 -0700 In-Reply-To: <41381BDF.1050700@gmx.de> References: <200407192004.QAA19839@ietf.org> <4130C4C0.7020609@gmx.de> <41376B5B.7020003@gmx.de> <56B66318-FD1C-11D8-A93D-000A95AACED2@xythos.com> <413780AE.5000605@gmx.de> <53F67CC4-FD2A-11D8-BF77-000A95B2BB72@osafoundation.org> <41381BDF.1050700@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDAV From: Brian Korver Date: Fri, 3 Sep 2004 10:08:55 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 03 Sep 2004 17:08:57.0488 (UTC) FILETIME=[B2F99100:01C491D8] 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: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/F042797F-FDCB-11D8-A93D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8785 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 Sep 2004 17:09:29 +0000 Content-Transfer-Encoding: 7bit On Sep 3, 2004, at 12:23 AM, Julian Reschke wrote: > Lisa Dusseault wrote: > Correct. So are you saying that > > (i) a system can't have both quotas and disk limits or > (ii) that we should have two different mechanisms? > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 Neither. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Sep 3 17:34: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 RAA16221 for ; Fri, 3 Sep 2004 17:34:36 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C3Lfd-0000t2-F6; Fri, 03 Sep 2004 21:32:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C3LfX-0000sW-Es for w3c-dist-auth@listhub.w3.org; Fri, 03 Sep 2004 21:32:27 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.104]) by lisa.w3.org with esmtp (Exim 4.34) id 1C3LfW-0000Zz-Kz for w3c-dist-auth@w3.org; Fri, 03 Sep 2004 21:32:26 +0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i83LVZvL848878; Fri, 3 Sep 2004 17:31:35 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i83LWhv7098930; Fri, 3 Sep 2004 17:32:44 -0400 In-Reply-To: <41389E3D.2090204@gmx.de> To: Julian Reschke Cc: Brian Korver , 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: Fri, 3 Sep 2004 17:31:29 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF433 | July 14, 2004) at 09/03/2004 17:31:34, Serialize complete at 09/03/2004 17:31:34 Content-Type: multipart/alternative; boundary="=_alternative 00763D9185256F04_=" 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/OF3ADEE31F.1AED466D-ON85256F04.00760075-85256F04.00763D94@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8786 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 Sep 2004 21:32:33 +0000 This is a multipart message in MIME format. --=_alternative 00763D9185256F04_= Content-Type: text/plain; charset="US-ASCII" I'm inclined to agree with Julian. A working group standard should be compatible with common industry models, unless those models are inherently incompatible. So an informational RFC seems more appropriate unless that compatibility is achieved. Cheers, Geoff Julian wrote on 09/03/2004 12:39:25 PM: > > Brian Korver wrote: > > > Anyone who is going to support this use case should speak up > > because if no one wants to support your proposed use case then > > the issue is moot. > > So you're saying that the fact that the protocol as specified is > incompatible with both the NTFS and Unix quota model is moot? > > As far as I can tell, the spec as currently published is optimized for > one very specific implementation. That's fine, unless people want to > make it *the* quota protocol with backing of the WebDAV working group. > > Please either simplify the protocol in a way so that other > implementations become possible (moving too specific features into > private extensions), or publish what you have as Informational RFC > describing what one specific system is supporting today. > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 00763D9185256F04_= Content-Type: text/html; charset="US-ASCII"
I'm inclined to agree with Julian.  A working group standard
should be compatible with common industry models, unless those
models are inherently incompatible.  So an informational RFC
seems more appropriate unless that compatibility is achieved.

Cheers,
Geoff


Julian wrote on 09/03/2004 12:39:25 PM:

>
> Brian Korver wrote:
>
> > Anyone who is going to support this use case should speak up
> > because if no one wants to support your proposed use case then
> > the issue is moot.
>
> So you're saying that the fact that the protocol as specified is
> incompatible with both the NTFS and Unix quota model is moot?
>
> As far as I can tell, the spec as currently published is optimized for
> one very specific implementation. That's fine, unless people want to
> make it *the* quota protocol with backing of the WebDAV working group.
>
> Please either simplify the protocol in a way so that other
> implementations become possible (moving too specific features into
> private extensions), or publish what you have as Informational RFC
> describing what one specific system is supporting today.
>
> Best regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 00763D9185256F04_=-- From w3c-dist-auth-request@w3.org Fri Sep 3 18:09: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 SAA18661 for ; Fri, 3 Sep 2004 18:09:11 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C3MDM-0002oa-Tb; Fri, 03 Sep 2004 22:07:24 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C3MDL-0002nk-IC; Fri, 03 Sep 2004 22:07:23 +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 1C3MDL-0003QS-9z; Fri, 03 Sep 2004 22:07:23 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Sep 2004 15:06:51 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8F0354A5-FDF5-11D8-A93D-000A95AACED2@xythos.com> Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org From: Brian Korver Date: Fri, 3 Sep 2004 15:06:51 -0700 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 03 Sep 2004 22:06:51.0497 (UTC) FILETIME=[50B6E590:01C49202] 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/8F0354A5-FDF5-11D8-A93D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8787 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 Sep 2004 22:07:24 +0000 Content-Transfer-Encoding: quoted-printable Geoff, I agree. And I agree with Julian that the "quota" model in the spec associates quota with resources, not users, which makes it inherently incompatible with the Unix model. But I don't think anyone could reasonably argue that the spec should be changed to associate quota with users. That would be unDAVlike, unNFSlike, etc. Of course, someone could unreasonably argue that position.... ;-) -brian briank@xythos.com On Sep 3, 2004, at 2:31 PM, Geoffrey M Clemm wrote: > I'm inclined to agree with Julian. =A0A working group standard > should be compatible with common industry models, unless those > models are inherently incompatible. =A0So an informational RFC > seems more appropriate unless that compatibility is achieved. > > Cheers, > Geoff > > > Julian wrote on 09/03/2004 12:39:25 PM: > > > > > Brian Korver wrote: > > > > > Anyone who is going to support this use case should speak up > > > because if no one wants to support your proposed use case then > > > the issue is moot. > > > > So you're saying that the fact that the protocol as specified is > > incompatible with both the NTFS and Unix quota model is moot? > > > > As far as I can tell, the spec as currently published is optimized=20= > for > > one very specific implementation. That's fine, unless people want = to > > make it *the* quota protocol with backing of the WebDAV working=20 > group. > > > > Please either simplify the protocol in a way so that other > > implementations become possible (moving too specific features into > > private extensions), or publish what you have as Informational RFC > > describing what one specific system is supporting today. > > > > Best regards, Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > From w3c-dist-auth-request@w3.org Sat Sep 4 04:00: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 EAA01290 for ; Sat, 4 Sep 2004 04:00:53 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C3VS9-0006St-BT; Sat, 04 Sep 2004 07:59:17 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C3VS8-0006Rg-ND for w3c-dist-auth@listhub.w3.org; Sat, 04 Sep 2004 07:59:16 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C3VS8-0007b7-9A for w3c-dist-auth@w3.org; Sat, 04 Sep 2004 07:59:16 +0000 Received: (qmail 13508 invoked by uid 65534); 4 Sep 2004 07:58:44 -0000 Received: from pD9535C21.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.92.33) by mail.gmx.net (mp001) with SMTP; 04 Sep 2004 09:58:44 +0200 X-Authenticated: #1915285 Message-ID: <413975A0.8090006@gmx.de> Date: Sat, 04 Sep 2004 09:58:24 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: Geoffrey M Clemm , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org References: <8F0354A5-FDF5-11D8-A93D-000A95AACED2@xythos.com> In-Reply-To: <8F0354A5-FDF5-11D8-A93D-000A95AACED2@xythos.com> Content-Type: text/plain; charset=us-ascii; 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/413975A0.8090006@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8788 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 Sep 2004 07:59:17 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > Geoff, > > I agree. And I agree with Julian that the "quota" model > in the spec associates quota with resources, not users, > which makes it inherently incompatible with the Unix model. > But I don't think anyone could reasonably argue that the > spec should be changed to associate quota with users. Well, we do. Many quota systems work like that; and if this is supposed to become the Quota spec supported by the IETF WebDAV mailing list, it should be compatible with these systems. Or on the other hand, removing this part of the spec resolves *that* issue, and as far as I can tell, only one single vendor is supporting it anyway. So why not make it a private extension? > That would be unDAVlike, unNFSlike, etc. Of course, someone > could unreasonably argue that position.... ;-) I don't get that point. Could you please explain...? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Sep 4 04:46: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 EAA03191 for ; Sat, 4 Sep 2004 04:46:13 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C3WA1-0001bB-8K; Sat, 04 Sep 2004 08:44:37 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C3WA0-0001af-IB; Sat, 04 Sep 2004 08:44:36 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.34) id 1C3WA0-0005Ur-4U; Sat, 04 Sep 2004 08:44:36 +0000 Received: from [192.168.0.3] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000041705.msg; Sat, 04 Sep 2004 10:44:30 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , Brian Korver , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org From: Stefan Eissing Date: Sat, 4 Sep 2004 10:44:25 +0200 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Sat, 04 Sep 2004 10:44:30 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/A0228180-FE4E-11D8-8D1F-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8789 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 Sep 2004 08:44:37 +0000 Content-Transfer-Encoding: quoted-printable Am 03.09.2004 um 23:31 schrieb Geoffrey M Clemm: > > I'm inclined to agree with Julian. =A0A working group standard > should be compatible with common industry models, unless those > models are inherently incompatible. =A0So an informational RFC > seems more appropriate unless that compatibility is achieved. I fully agree. //Stefan From w3c-dist-auth-request@w3.org Sun Sep 5 13:36: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 NAA11944 for ; Sun, 5 Sep 2004 13:36:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C40uA-00063h-Os; Sun, 05 Sep 2004 17:34:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C40uA-00063B-6N for w3c-dist-auth@listhub.w3.org; Sun, 05 Sep 2004 17:34: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 1C40u9-0002H6-1n for w3c-dist-auth@w3.org; Sun, 05 Sep 2004 17:34:17 +0000 Received: (qmail 30360 invoked by uid 65534); 5 Sep 2004 17:33:45 -0000 Received: from pD9E51C7D.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.125) by mail.gmx.net (mp011) with SMTP; 05 Sep 2004 19:33:45 +0200 X-Authenticated: #1915285 Message-ID: <413B4DEC.1030201@gmx.de> Date: Sun, 05 Sep 2004 19:33:32 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: Joe Hildebrand References: <8D96EDA0AC04D31197B400A0C96C14800E2C646D@corp.webb.net> <41260721.2040707@gmx.de> In-Reply-To: <41260721.2040707@gmx.de> Content-Type: text/plain; charset=us-ascii; 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: Notes from IETF-60 WebDAV WG Meeting X-Archived-At: http://www.w3.org/mid/413B4DEC.1030201@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8790 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: Sun, 05 Sep 2004 17:34:18 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > Joe Hildebrand wrote: > >> BINDINGS >> >> ... >> >> Roy suggested to address only the real interoperability problems. Ted >> thought the draft needs clarification on some possible scenarios. Ted >> suggested that an explicit call to the mailing list seems necessary >> regarding whether we need clarifying text on the point mentioned (text >> already provided by LD on list). > > > > I haven't seen any new mails regarding this topic in the last few weeks. OK, I'm still not sure what this point is (if anybody is aware about exactly what mail this refers to, by all means supply a pointer). Anyway: what's our plan in order to make progress on this issue? According to our just recently updated charter (), the BIND spec should have been in (WG-) last call for over three months now. Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Sep 5 23:32: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 XAA12450 for ; Sun, 5 Sep 2004 23:32:24 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4AD9-0008Tv-HD; Mon, 06 Sep 2004 03:30:31 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C4AD8-0008TH-IQ for w3c-dist-auth@listhub.w3.org; Mon, 06 Sep 2004 03:30:30 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1C4AD8-0006KJ-4n for w3c-dist-auth@w3.org; Mon, 06 Sep 2004 03:30:30 +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 i863UGpp015888 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 5 Sep 2004 20:30:22 -0700 In-Reply-To: <413B4DEC.1030201@gmx.de> References: <8D96EDA0AC04D31197B400A0C96C14800E2C646D@corp.webb.net> <41260721.2040707@gmx.de> <413B4DEC.1030201@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0D1D2D6A-FFB5-11D8-BF77-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org, Joe Hildebrand From: Lisa Dusseault Date: Sun, 5 Sep 2004 20:30:08 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (bart.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Notes from IETF-60 WebDAV WG Meeting X-Archived-At: http://www.w3.org/mid/0D1D2D6A-FFB5-11D8-BF77-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8791 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 Sep 2004 03:30:31 +0000 Content-Transfer-Encoding: 7bit How about a fuller response after the American long weekend (after Monday)? August is full of vacations for many. Lisa On Sep 5, 2004, at 10:33 AM, Julian Reschke wrote: > > Julian Reschke wrote: > > > Joe Hildebrand wrote: > > > >> BINDINGS > >> > >> ... > >> > >> Roy suggested to address only the real interoperability problems. > Ted > >> thought the draft needs clarification on some possible scenarios. > Ted > >> suggested that an explicit call to the mailing list seems necessary > >> regarding whether we need clarifying text on the point mentioned > (text > >> already provided by LD on list). > > > > > > > > I haven't seen any new mails regarding this topic in the last few > weeks. > > > OK, I'm still not sure what this point is (if anybody is aware about > exactly what mail this refers to, by all means supply a pointer). > > Anyway: what's our plan in order to make progress on this issue? > > According to our just recently updated charter > (), the BIND > spec should have been in (WG-) last call for over three months now. > > Feedback appreciated, > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > From w3c-dist-auth-request@w3.org Mon Sep 6 03:39: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 DAA08326 for ; Mon, 6 Sep 2004 03:39:16 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4E3q-0003pO-QA; Mon, 06 Sep 2004 07:37:10 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C4E3q-0003on-80 for w3c-dist-auth@listhub.w3.org; Mon, 06 Sep 2004 07:37:10 +0000 Received: from chandgate.mahindrabt.com ([202.75.195.52]) by bart.w3.org with esmtp (Exim 4.34) id 1C4E3p-0005XA-9j for w3c-dist-auth@w3.org; Mon, 06 Sep 2004 07:37:10 +0000 Received: from interscan (imss1.chand.mahindrabt.com [10.3.0.65]) by chandgate.mahindrabt.com (8.12.10/8.12.10) with ESMTP id i867iKJ5009378 for ; Mon, 6 Sep 2004 13:14:20 +0530 Received: from intranet.chand.mahindrabt.com ([10.3.0.2]) by interscan with InterScan Messaging Security Suite; Mon, 06 Sep 2004 13:11:42 +0530 Received: from british-s9m83vo ([10.3.0.150])by intranet.chand.mahindrabt.com (8.12.10/8.12.10) with ESMTP id i867h640003480for ; Mon, 6 Sep 2004 13:13:07 +0530 Received: from dscp05301a ([10.3.8.151]) by british-s9m83vo with InterScan Messaging Security Suite; Mon, 06 Sep 2004 13:12:38 +0530 Message-ID: <00c401c493e6$2c935230$9708030a@mahindrabt.com> From: "Varun" To: Date: Mon, 6 Sep 2004 13:20:25 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C1_01C49414.459ED370" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Received-SPF: none (bart.w3.org: domain of varunp@mahindrabt.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Platform for WebDav Development X-Archived-At: http://www.w3.org/mid/00c401c493e6$2c935230$9708030a@mahindrabt.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8792 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 Sep 2004 07:37:10 +0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C1_01C49414.459ED370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I need to develope one interface which picks data from a RDBMS and puts in= exchange server 2000.=0D Restriction is that the interface exe should not do the processing on the= exchange server, but it should reside and run from a different machine. I need to know how can I use WebDav to achieve this and what are the= possible development platforms for this? Regards -Varun ********************************************************* Disclaimer: =0D This message (including any attachments) contains=0D confidential information intended for a specific=0D individual and purpose, and is protected by law.=0D If you are not the intended recipient, you should=0D delete this message and are hereby notified that=0D any disclosure, copying, or distribution of this message, or the taking of any action based on it,=0D is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_00C1_01C49414.459ED370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I need to develope one interface which=0D picks data from a RDBMS and puts in exchange server 2000.=
Restriction is that the interface exe= should not do=0D the processing on the exchange server, but it should reside and run from a= =0D different machine.
I need to know how can I use WebDav= to achieve=0D this and what are the possible development platforms for this?
 
Regards
-Varun
 
*********************************************************
Dis= claimer:

This message (including any attachments) contains=
confidential information intended for a specific
individual and= purpose, and is protected by law.
If you are not the intended= recipient, you should
delete this message and are hereby notified that=
any disclosure, copying, or distribution of this
message, or the= taking of any action based on it,
is strictly= prohibited.

*******************************************************= **
Visit us at= http://www.mahindrabt.com



------=_NextPart_000_00C1_01C49414.459ED370-- From w3c-dist-auth-request@w3.org Mon Sep 6 04:17: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 EAA13185 for ; Mon, 6 Sep 2004 04:17:27 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4EfZ-0007qL-MD; Mon, 06 Sep 2004 08:16:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C4EfY-0007ph-Fs for w3c-dist-auth@listhub.w3.org; Mon, 06 Sep 2004 08:16:08 +0000 Received: from [202.151.157.74] (helo=igsblrrel.igate.com) by lisa.w3.org with esmtp (Exim 4.34) id 1C4EfW-00081z-M6 for w3c-dist-auth@w3.org; Mon, 06 Sep 2004 08:16:07 +0000 Received: from igteblrowa02.igatecorp.com (dmz-cisco [172.16.10.5]) by igsblrrel.igate.com (8.12.5/8.12.5) with ESMTP id i868kQfc012525; Mon, 6 Sep 2004 14:17:34 +0530 Received: from igteblrexc04.igatecorp.com ([192.168.210.113]) by igteblrowa02.igatecorp.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 6 Sep 2004 13:43:29 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C493E9.646297A4" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Mon, 6 Sep 2004 13:43:29 +0530 Message-ID: Thread-Topic: Platform for WebDav Development Thread-Index: AcST5KZ7+isgmsRVS6+F2BYwRh3wUwAA08pA From: "Gangadhar Pai" To: "Varun" , X-OriginalArrivalTime: 06 Sep 2004 08:13:29.0624 (UTC) FILETIME=[6483D180:01C493E9] Received-SPF: none (lisa.w3.org: domain of Gangadhar.Pai@igate.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Platform for WebDav Development X-Archived-At: http://www.w3.org/mid/FCE110FFAA26324686F5A3F1954D00DA0D292E@igteblrexc04.igatecorp.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8793 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 Sep 2004 08:16:09 +0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C493E9.646297A4 Content-Type: text/plain; charset="iso-8859-1" X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Content-Transfer-Encoding: quoted-printable You will have to write a proxy server which will act as an conduit betwee= n the data source(RDBMS) and Content server(Exchange 2000) =20 This server should be an HTTP server with additional WebDAV support, for = this you can consider IIS with ISAPI filters and Extension. ODBC/OLE DB for RDBMS interface. Or parallely any Java Based HTTP server = with JDBC support. =20 For typical CRUD operations following WebDAV methods should suffice: 1) Propfind (for read), Proppatch(create, update), Move or Delete(for del= ete) and Search(for querying), if you want this operation in a batch(Bulk= ) you can consider BPropfind, BProppatch etc. =20 =20 Regards Gangadhar Pai=20 |Project Manager| iGATE Global Solutions | email: gangadhar.pai@igate.com= < mailto:gangadhar.pai@igate.com> | Website: < http://paionline.tripod.c= om > | =20 =20 =20 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]O= n Behalf Of Varun Sent: Monday, September 06, 2004 1:20 PM To: w3c-dist-auth@w3.org Subject: Platform for WebDav Development Hi, I need to develope one interface which picks data from a RDBMS and puts i= n exchange server 2000.=20 Restriction is that the interface exe should not do the processing on the= exchange server, but it should reside and run from a different machine. I need to know how can I use WebDav to achieve this and what are the poss= ible development platforms for this? =20 Regards -Varun =20 ********************************************************* Disclaimer:=20 This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com =09 Information transmitted by this EMAIL is proprietary to iGATE Group of Co= mpanies and is intended for use only by the individual or entity to whom = it is addressed and may contain information that is privileged, confident= ial, or exempt from disclosure under applicable law. If you are not the i= ntended recipient of this EMAIL immediately notify the sender at iGATE or= mailadmin@igate.com and delete this EMAIL including any attachments. ------_=_NextPart_001_01C493E9.646297A4 Content-Type: text/HTML; charset="iso-8859-1" X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Content-Transfer-Encoding: quoted-printable
You=20 will have to write a proxy server which will act as an conduit between th= e data=20 source(RDBMS) and Content server(Exchange 2000)
 
This=20 server should be an HTTP server with additional WebDAV support, for this = you can=20 consider IIS with ISAPI filters and Extension.
ODBC/OLE DB for RDBMS interface. Or parallely any Java Base= d HTTP=20 server with JDBC support.
 
For=20 typical CRUD operations following WebDAV methods should=20 suffice:
1)=20 Propfind (for read), Proppatch(create, update), Move or Delete(for=20 delete) and Search(for querying), if you want this operation in a=20 batch(Bulk) you can consider BPropfind, BProppatch =20 etc.
 
 
Regards
Ga= ngadhar=20 Pai
|Project M= anager| iGATE=20 Global Solutions | email: gangadhar.pai@igate.com <mailto:gangadhar.pai@igate.com> | Website: <http://paionline.tripod.com> |

 

 
 
-----Original Message-----
From: w3c-dist-auth-reque= st@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Varun
Se= nt:=20 Monday, September 06, 2004 1:20 PM
To:=20 w3c-dist-auth@w3.org
Subject: Platform for WebDav=20 Development

Hi,
I need to develope one interface which= =20 picks data from a RDBMS and puts in exchange server 2000. <= /DIV>
Restriction is that the interface exe = should not=20 do the processing on the exchange server, but it should reside and run = from a=20 different machine.
I need to know how can I use WebD= av to=20 achieve this and what are the possible development platforms for=20 this?
 
Regards
-Varun
 

Information transmitted by this EMAIL is proprietary to iGATE Group of Co= mpanies and is intended for use only by the individual or entity to whom = it is addressed and may contain information that is privileged, confident= ial, or exempt from disclosure under applicable law. If you are not the i= ntended recipient of this EMAIL immediately notify the sender at iGATE or= mailadmin@igate.com and delete this EMAIL including any attachments.

------_=_NextPart_001_01C493E9.646297A4-- From w3c-dist-auth-request@w3.org Mon Sep 6 05:14: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 FAA16293 for ; Mon, 6 Sep 2004 05:14:46 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4FZ2-0000Ho-IJ; Mon, 06 Sep 2004 09:13:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C4FZ1-0000HA-T3 for w3c-dist-auth@listhub.w3.org; Mon, 06 Sep 2004 09:13:27 +0000 Received: from chandgate.mahindrabt.com ([202.75.195.52]) by lisa.w3.org with esmtp (Exim 4.34) id 1C4FYz-000798-Ql for w3c-dist-auth@w3.org; Mon, 06 Sep 2004 09:13:26 +0000 Received: from interscan (imss1.chand.mahindrabt.com [10.3.0.65]) by chandgate.mahindrabt.com (8.12.10/8.12.10) with ESMTP id i869KbJ5023111 for ; Mon, 6 Sep 2004 14:50:37 +0530 Received: from intranet.chand.mahindrabt.com ([10.3.0.2]) by interscan with InterScan Messaging Security Suite; Mon, 06 Sep 2004 14:48:00 +0530 Received: from british-s9m83vo ([10.3.0.150])by intranet.chand.mahindrabt.com (8.12.10/8.12.10) with ESMTP id i869JOiv016990for ; Mon, 6 Sep 2004 14:49:25 +0530 Received: from dscp05301a ([10.3.8.151]) by british-s9m83vo with InterScan Messaging Security Suite; Mon, 06 Sep 2004 14:48:55 +0530 Message-ID: <013a01c493f3$a080d430$9708030a@mahindrabt.com> From: "Varun" To: Date: Mon, 6 Sep 2004 14:56:44 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0137_01C49421.B9EFAB20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:11 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Received-SPF: none (lisa.w3.org: domain of varunp@mahindrabt.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Platform for WebDav Development X-Archived-At: http://www.w3.org/mid/013a01c493f3$a080d430$9708030a@mahindrabt.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8794 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 Sep 2004 09:13:28 +0000 This is a multi-part message in MIME format. ------=_NextPart_000_0137_01C49421.B9EFAB20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI ----- Original Message -----=0D From: Varun=0D To: Gangadhar Pai=0D Sent: Monday, September 06, 2004 2:23 PM Subject: Re: Platform for WebDav Development Thanks a lot for educating me on that. I am new to WebDav methods, as i have worked only on client server= applications using RDBMS databases and worked on VB/Vb.net and ASP.net= only. I have few questions, if possible help me out. 1) I need to know about the development languages which I can use for= writing the code. 2) Can I make the interface using standard exe in vb or vb.net? 3) Can I use Ado and any any oledb provider for connectivity to exchange= server? Has cdoex any role to play in WebDav?=0D Thanks & Regards -Varun ----- Original Message -----=0D From: Gangadhar Pai=0D To: Varun ; w3c-dist-auth@w3.org=0D Sent: Monday, September 06, 2004 1:43 PM Subject: RE: Platform for WebDav Development You will have to write a proxy server which will act as an conduit= between the data source(RDBMS) and Content server(Exchange 2000) This server should be an HTTP server with additional WebDAV support,= for this you can consider IIS with ISAPI filters and Extension. ODBC/OLE DB for RDBMS interface. Or parallely any Java Based HTTP= server with JDBC support. For typical CRUD operations following WebDAV methods should suffice: 1) Propfind (for read), Proppatch(create, update), Move or Delete(for= delete) and Search(for querying), if you want this operation in a= batch(Bulk) you can consider BPropfind, BProppatch etc. Regards Gangadhar Pai=0D |Project Manager| iGATE Global Solutions | email:= gangadhar.pai@igate.com | Website:= | -----Original Message----- From: w3c-dist-auth-request@w3.org= [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Varun Sent: Monday, September 06, 2004 1:20 PM To: w3c-dist-auth@w3.org Subject: Platform for WebDav Development Hi, I need to develope one interface which picks data from a RDBMS and= puts in exchange server 2000.=0D Restriction is that the interface exe should not do the processing on= the exchange server, but it should reside and run from a different= machine. I need to know how can I use WebDav to achieve this and what are the= possible development platforms for this? Regards -Varun ********************************************************* Disclaimer:=0D This message (including any attachments) contains=0D confidential information intended for a specific=0D individual and purpose, and is protected by law.=0D If you are not the intended recipient, you should=0D delete this message and are hereby notified that=0D any disclosure, copying, or distribution of this message, or the taking of any action based on it,=0D is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com =0D ---------------------------------------------------------------------------= - Information transmitted by this EMAIL is proprietary to iGATE Group of= Companies and is intended for use only by the individual or entity to whom= it is addressed and may contain information that is privileged,= confidential, or exempt from disclosure under applicable law. If you are= not the intended recipient of this EMAIL immediately notify the sender at= iGATE or mailadmin@igate.com and delete this EMAIL including any= attachments.=0D ********************************************************* Disclaimer: =0D This message (including any attachments) contains=0D confidential information intended for a specific=0D individual and purpose, and is protected by law.=0D If you are not the intended recipient, you should=0D delete this message and are hereby notified that=0D any disclosure, copying, or distribution of this message, or the taking of any action based on it,=0D is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_0137_01C49421.B9EFAB20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
FYI
----- Original Message -----
From:=0D Varun=0D
Sent: Monday, September 06, 2004= 2:23=0D PM
Subject: Re: Platform for WebDav=0D Development

Thanks a lot for educating me on=0D that.
 
I am new to WebDav methods, as i have= worked only=0D on client server applications using RDBMS databases and worked on= VB/Vb.net=0D and ASP.net only.
 
I have few questions, if possible help me out.
 
1) I need to know about the development= languages=0D which I can use for writing the code.
 
2) Can I make the interface using= standard=0D exe in vb or vb.net?
 
3) Can I use Ado and any any oledb= provider for=0D connectivity to exchange server? Has cdoex any role to play in=0D WebDav? 
 
Thanks & Regards
-Varun
 
----- Original Message -----
From:=0D Gangadhar Pai
To: Varun ; w3c-dist-auth@w3.org
Sent: Monday, September 06, 2004= 1:43=0D PM
Subject: RE: Platform for WebDav= =0D Development

You will have to write a proxy server which will act as an= conduit=0D between the data source(RDBMS) and Content server(Exchange=0D 2000)
 
This server should be an HTTP server with additional WebDAV= support,=0D for this you can consider IIS with ISAPI filters and=0D Extension.
ODBC/OLE DB for RDBMS interface. Or parallely any Java= Based=0D HTTP server with JDBC support.
 
For typical CRUD operations following WebDAV methods should=0D suffice:
1)=0D Propfind (for read), Proppatch(create, update), Move or Delete(for=0D delete) and Search(for querying), if you want this operation in a= =0D batch(Bulk) you can consider BPropfind, BProppatch =0D etc.
 
 
Regards
Gangadhar=0D Pai
|Project= Manager|=0D iGATE Global Solutions | email: gangadhar.pai@igate.com <mailto:gangadhar.pai@igate.com><= /FONT> | Website: <http://paionline.tripod.com> |

 

 
 
-----Original Message-----
From:=0D w3c-dist-auth-request@w3.org= [mailto:w3c-dist-auth-request@w3.org]On=0D Behalf Of Varun
Sent: Monday, September 06, 2004 1:20=0D PM
To: w3c-dist-auth@w3.org
Subject: Platform for= =0D WebDav Development

Hi,
I need to develope one interface= which=0D picks data from a RDBMS and puts in exchange server 2000.=0D
Restriction is that the interface= exe should=0D not do the processing on the exchange server, but it should reside= and run=0D from a different machine.
I need to know how can I use= WebDav to=0D achieve this and what are the possible development platforms for=0D this?
 
Regards
-Varun
 
*************************************************= ********
Disclaimer:=20

This message (including any attachments) contains=20
confidential information intended for a specific
individu= al and=20 purpose, and is protected by law.
If you are not the intended= =20 recipient, you should
delete this message and are hereby noti= fied=20 that
any disclosure, copying, or distribution of this
mess= age, or=20 the taking of any action based on it,
is strictly=20 prohibited.

**********************************************= ***********
Visit=20 us at=20 http://www.mahindrabt.com
*********************************************************
Dis= claimer:=0D

This message (including any attachments) contains=0D
confidential information intended for a specific=
individual=0D and purpose, and is protected by law.
If you are not the=0D intended recipient, you should
delete this message and are= =0D hereby notified that
any disclosure, copying, or= distribution of=0D this
message, or the taking of any action based on it,=
is=0D strictly=0D = prohibited.

*******************************************************= **
Visit=0D us at=0D = http://www.mahindrabt.com



=

Information transmitted by this EMAIL is proprietary to iGATE Group of= =0D Companies and is intended for use only by the individual or entity to= whom=0D it is addressed and may contain information that is privileged,=0D confidential, or exempt from disclosure under applicable law. If you= are not=0D the intended recipient of this EMAIL immediately notify the sender at= iGATE=0D or mailadmin@igate.com and delete this EMAIL including any attachments.= =0D

*********************************************************
Dis= claimer:

This message (including any attachments) contains=
confidential information intended for a specific
individual and= purpose, and is protected by law.
If you are not the intended= recipient, you should
delete this message and are hereby notified that=
any disclosure, copying, or distribution of this
message, or the= taking of any action based on it,
is strictly= prohibited.

*******************************************************= **
Visit us at= http://www.mahindrabt.com



------=_NextPart_000_0137_01C49421.B9EFAB20-- From w3c-dist-auth-request@w3.org Tue Sep 7 00:36: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 AAA29902 for ; Tue, 7 Sep 2004 00:36:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4Xgi-00027n-J7; Tue, 07 Sep 2004 04:34:36 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C4Xgh-00027H-Oa for w3c-dist-auth@listhub.w3.org; Tue, 07 Sep 2004 04:34:35 +0000 Received: from m1005.hostcentric.net ([66.40.206.251]) by bart.w3.org with smtp (Exim 4.34) id 1C4Xgg-0006xF-Sc for w3c-dist-auth@w3.org; Tue, 07 Sep 2004 04:34:35 +0000 Received: (qmail 22769 invoked by alias); 7 Sep 2004 04:34:03 -0000 Received: from unknown (HELO developer3) (213.217.46.156) by 0 with SMTP; 7 Sep 2004 04:34:03 -0000 From: "Farhad" To: "'Varun'" , , Date: Tue, 7 Sep 2004 09:03:39 +0330 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C494B9.97636270" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSUJFR2l53MGG1RTMuf9PVilCNfAwAdalLQ In-Reply-To: <013a01c493f3$a080d430$9708030a@mahindrabt.com> Received-SPF: none (bart.w3.org: domain of f.siasar@bornaray.com does not designate permitted sender hosts) Message-ID: X-Original-To: w3c-dist-auth@w3.org Subject: RE: Platform for WebDav Development X-Archived-At: http://www.w3.org/mid/E1C4Xgh-00027H-Oa@frink.w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8795 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 Sep 2004 04:34:36 +0000 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C494B9.97636270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I used Vb.net for handle requests, so I add a wild card filter, on windows server 2003 And tried to handle request verbs, In response to "Propfind", Regarding to "rfc2518" http://www.webdav.org/specs/rfc2518.htm or others, we've got that the response object must return Some XML But I do not know how can I make XML for my situation and how can I append this XML to response object Is there anybody to help me? _____ From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Varun Sent: Monday, September 06, 2004 12:57 PM To: w3c-dist-auth@w3.org Subject: Re: Platform for WebDav Development FYI ----- Original Message ----- From: Varun To: Gangadhar Pai Sent: Monday, September 06, 2004 2:23 PM Subject: Re: Platform for WebDav Development Thanks a lot for educating me on that. I am new to WebDav methods, as i have worked only on client server applications using RDBMS databases and worked on VB/Vb.net and ASP.net only. I have few questions, if possible help me out. 1) I need to know about the development languages which I can use for writing the code. 2) Can I make the interface using standard exe in vb or vb.net? 3) Can I use Ado and any any oledb provider for connectivity to exchange server? Has cdoex any role to play in WebDav? Thanks & Regards -Varun ----- Original Message ----- From: Gangadhar Pai To: Varun ; w3c-dist-auth@w3.org Sent: Monday, September 06, 2004 1:43 PM Subject: RE: Platform for WebDav Development You will have to write a proxy server which will act as an conduit between the data source(RDBMS) and Content server(Exchange 2000) This server should be an HTTP server with additional WebDAV support, for this you can consider IIS with ISAPI filters and Extension. ODBC/OLE DB for RDBMS interface. Or parallely any Java Based HTTP server with JDBC support. For typical CRUD operations following WebDAV methods should suffice: 1) Propfind (for read), Proppatch(create, update), Move or Delete(for delete) and Search(for querying), if you want this operation in a batch(Bulk) you can consider BPropfind, BProppatch etc. Regards Gangadhar Pai |Project Manager| iGATE Global Solutions | email: gangadhar.pai@igate.com | Website: > | -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Varun Sent: Monday, September 06, 2004 1:20 PM To: w3c-dist-auth@w3.org Subject: Platform for WebDav Development Hi, I need to develope one interface which picks data from a RDBMS and puts in exchange server 2000. Restriction is that the interface exe should not do the processing on the exchange server, but it should reside and run from a different machine. I need to know how can I use WebDav to achieve this and what are the possible development platforms for this? Regards -Varun ********************************************************* Disclaimer: This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _____ Information transmitted by this EMAIL is proprietary to iGATE Group of Companies and is intended for use only by the individual or entity to whom it is addressed and may contain information that is privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient of this EMAIL immediately notify the sender at iGATE or mailadmin@igate.com and delete this EMAIL including any attachments. ********************************************************* Disclaimer: This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_0009_01C494B9.97636270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I used Vb.net = for handle requests, so I add a wild card filter, on windows server = 2003

And tried to = handle request verbs,

In response to = "Propfind", Regarding to "rfc2518" http://www.webdav.org/sp= ecs/rfc2518.htm  or = others, we've got that the response object must return

Some XML

But I do not know how can I make XML for my situation and = how can I append this XML to response object

Is there anybody to help me?

 =

From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On Behalf Of Varun
Sent: Monday, September = 06, 2004 12:57 PM
To: = w3c-dist-auth@w3.org
Subject: Re: Platform for = WebDav Development

 

FYI

----- Original Message ----- =

From: Varun

Sent: Monday, = September 06, 2004 2:23 PM

Subject: Re: Platform for WebDav Development

 

Thanks a lot for educating me on = that.

 

I am new to WebDav methods, as i have worked only on = client server applications using RDBMS databases and worked on VB/Vb.net and = ASP.net only.

 

I have few questions, if possible help me = out.

 

1) I need to know about the development languages which I can use for writing the code.

 

2) Can I make the interface using standard exe = in vb or vb.net?

 

3) Can I use Ado and any any oledb provider for connectivity to exchange server? Has = cdoex any role to play in WebDav? 

 

Thanks & Regards

-Varun

 

----- Original Message ----- =

Sent: Monday, = September 06, 2004 1:43 PM

Subject: RE: Platform for WebDav Development

 

You will have to = write a proxy server which will act as an conduit between the data source(RDBMS) = and Content server(Exchange 2000)

 

This server = should be an HTTP server with additional WebDAV support, for this you can consider = IIS with ISAPI filters and Extension.

ODBC/OLE = DB for RDBMS interface. Or parallely any Java Based HTTP server with JDBC = support.

 

For typical CRUD operations following WebDAV methods should = suffice:

1) Propfind (for = read), Proppatch(create, update), Move or Delete(for delete) and = Search(for querying), if you want this operation in a batch(Bulk) you can consider BPropfind, BProppatch  etc.

 

 

Regards

Gangadhar = Pai
|Project Manager| iGATE Global = Solutions | email: = gangadhar.pai@igate.com <mailto:gangadhar.pai@igate.com> | Website: <http://paionline.tripod.com> |

 

 

 

-----Original Message-----
From: = w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Varun
Sent: Monday, September = 06, 2004 1:20 PM
To: = w3c-dist-auth@w3.org
Subject: Platform for = WebDav Development

Hi,

I need to develope one interface which = picks data from a RDBMS and puts in exchange server 2000.

Restriction is that the interface exe should not do = the processing on the exchange server, but it should reside and run from a different machine.

I need to know how can I use WebDav to achieve = this and what are the possible development platforms for = this?

 

Regards

-Varun

 

**********************************= ***********************
Disclaimer:

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

Information transmitted by this EMAIL is = proprietary to iGATE Group of Companies and is intended for use only by the = individual or entity to whom it is addressed and may contain information that is = privileged, confidential, or exempt from disclosure under applicable law. If you are = not the intended recipient of this EMAIL immediately notify the sender at = iGATE or mailadmin@igate.com and delete this EMAIL including any attachments. =

*********************************************************=
Disclaimer:

This message (including any = attachments) contains
confidential information intended for a = specific
individual and purpose, and is protected by law.
If you = are not the intended recipient, you should
delete this message and = are hereby notified that
any disclosure, copying, or distribution of = this
message, or the taking of any action based on it,
is = strictly = prohibited.

******************************************************= ***
Visit us at = http://www.mahindrabt.com



------=_NextPart_000_0009_01C494B9.97636270-- From w3c-dist-auth-request@w3.org Tue Sep 7 16:46: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 QAA03189 for ; Tue, 7 Sep 2004 16:46:34 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4mpi-0001zl-EG; Tue, 07 Sep 2004 20:44:54 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C4mpg-0001yy-GE for w3c-dist-auth@listhub.w3.org; Tue, 07 Sep 2004 20:44:52 +0000 Received: from relay.freeuk.net ([212.126.144.54]) by bart.w3.org with esmtp (Exim 4.34) id 1C4mpg-0000dN-3q for w3c-dist-auth@w3.org; Tue, 07 Sep 2004 20:44:52 +0000 Received: from adsl-167-115.freeuk.com ([80.168.167.115] helo=voodoo) by relay.freeuk.net with smtp (Exim 4.34) id 1C4mpf-000NHV-7n for w3c-dist-auth@w3.org; Tue, 07 Sep 2004 21:44:51 +0100 Message-ID: <001801c4951b$8b5ed4c0$f400a8c0@voodoo> Reply-To: "Elliott" From: "Elliott" To: Date: Tue, 7 Sep 2004 21:44:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Received-SPF: none (bart.w3.org: domain of elliott@elliottonline.co.uk does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: WebDAV project X-Archived-At: http://www.w3.org/mid/001801c4951b$8b5ed4c0$f400a8c0@voodoo Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8796 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 Sep 2004 20:44:54 +0000 Content-Transfer-Encoding: 7bit Dear List, I am final year student about to embark on my final year project. I recently came into contact with WebDAV through an evaluation copy of SuSE Open Exchange 4.1. I would like to learn more and if possible integrate WebDAV into my final year project. I am trying to find a project title that will solve a practical problem with a view to building some application or product. I had hoped that I would find an unfinished project within the WebDAV project or possibly some one has an idea to utlise WebDAV to solve a problem and they would like some input from an enthusiastic student. Any suggestions would be greatly appreciated. Yours hopefully Elliott Chandler From w3c-dist-auth-request@w3.org Tue Sep 7 16:47: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 QAA03403 for ; Tue, 7 Sep 2004 16:47:27 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4mrF-0003Ic-Kl; Tue, 07 Sep 2004 20:46:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C4mrF-0003HK-5I for w3c-dist-auth@listhub.w3.org; Tue, 07 Sep 2004 20:46:29 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C4mrD-0006iA-P4 for w3c-dist-auth@w3c.org; Tue, 07 Sep 2004 20:46:28 +0000 Received: (qmail 16216 invoked by uid 65534); 5 Sep 2004 14:59:15 -0000 Received: from pD9E51C7D.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.125) by mail.gmx.net (mp025) with SMTP; 05 Sep 2004 16:59:15 +0200 X-Authenticated: #1915285 Message-ID: <413B29B7.8050707@gmx.de> Date: Sun, 05 Sep 2004 16:59:03 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3c.org CC: Joe Hildebrand References: <8D96EDA0AC04D31197B400A0C96C14800E2C646D@corp.webb.net> <41260721.2040707@gmx.de> In-Reply-To: <41260721.2040707@gmx.de> Content-Type: text/plain; charset=us-ascii; 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: Notes from IETF-60 WebDAV WG Meeting X-Archived-At: http://www.w3.org/mid/413B29B7.8050707@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8797 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 Sep 2004 20:46:29 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > Joe Hildebrand wrote: >> BINDINGS >> >> ... >> >> Roy suggested to address only the real interoperability problems. Ted >> thought the draft needs clarification on some possible scenarios. Ted >> suggested that an explicit call to the mailing list seems necessary >> regarding whether we need clarifying text on the point mentioned (text >> already provided by LD on list). > > > I haven't seen any new mails regarding this topic in the last few weeks. OK, I'm still not sure what this point is (if anybody is aware about exactly what mail this refers to, by all means supply a pointer). Anyway: what's our plan in order to make progress on this issue? According to our just recently updated charter (), the BIND spec should have been in (WG-) last call for over three months now. Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Sep 7 17:14: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 RAA07694 for ; Tue, 7 Sep 2004 17:14:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4nH0-0001px-Da; Tue, 07 Sep 2004 21:13:06 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C4nGz-0001pM-Pw for w3c-dist-auth@listhub.w3.org; Tue, 07 Sep 2004 21:13:05 +0000 Received: from natnoddy.rzone.de ([81.169.145.166]) by bart.w3.org with esmtp (Exim 4.34) id 1C4nGz-0004tz-AD for w3c-dist-auth@w3c.org; Tue, 07 Sep 2004 21:13:05 +0000 Received: from x.oberon.ethz.ch (G73e1.g.pppool.de [80.185.115.225]) by post.webmailer.de (8.12.10/8.12.10) with SMTP id i83JeSCg002153; Fri, 3 Sep 2004 21:40:29 +0200 (MEST) Date: Fri, 3 Sep 2004 21:40:28 +0200 (MEST) Message-Id: <200409031940.i83JeSCg002153@post.webmailer.de> From: edgar@edgarschwarz.de X-Mailer: Oberon Mail (ejz) on Aos 20.02.2004 To: w3c-dist-auth@w3c.org, ietf-http-wg@w3.org Cc: edgar@edgarschwarz.de Received-SPF: none (bart.w3.org: domain of edgar@edgarschwarz.de does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re (2): quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt X-Archived-At: http://www.w3.org/mid/200409031940.i83JeSCg002153@post.webmailer.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8798 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 Sep 2004 21:13:06 +0000 Julian Reschke wrote: > Lisa Dusseault wrote: > > > > > > This also a matter of wording. Perhaps negatives should be avoided in conditions. So what about: D:quota-met ? Ok, it would be better it we had something like D:unmet-condition (Probably D:condition would be good enough together with an HTTP error code) instead of D:error. But I can live with it. > > > > and think "Huh? My error is that quota is not exceeded? what's up with > > that? " I can even imagine bugs logged against implementors who > > correctly follow the spec. > > On the other hand, implementors may be accustomed with the terminology > used by RFC3253, RFC3648 and RFC3744, and become confused by a new spec > being inconsistent with it. > > Also, people seeing DAV:error (and not already familiar with RFC3253) > will hopefully find the specification, which will point them to RFC3253, > section 1.6, which explains it all. I agree that it's surprising at first, Lisa. OTOH pre- and postconditions are a fine concept IMHO. Remember a computer language from the Middle Ages called Eiffel ;-? So even if it was done differently in former times I would go with RFC3253, RFC3648, RFC3744 and Julian in the future. Cheers, Edgar -- edgar@edgarschwarz.de, Running Bluebottle www.edgarschwarz.de Make it as simple as possible, but not simpler ! Albert Einstein www.edgar-schwarz.de/cgi-bin/moin/ www.edgar-schwarz.de/cgi-bin/moin/SwOberon From w3c-dist-auth-request@w3.org Tue Sep 7 17:44: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 RAA09812 for ; Tue, 7 Sep 2004 17:44:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4njy-0002Gi-Iy; Tue, 07 Sep 2004 21:43:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C4njx-0002Fs-RM; Tue, 07 Sep 2004 21:43:01 +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 1C4njw-0005kI-NA; Tue, 07 Sep 2004 21:43:00 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 14:42:27 -0700 In-Reply-To: <413975A0.8090006@gmx.de> References: <8F0354A5-FDF5-11D8-A93D-000A95AACED2@xythos.com> <413975A0.8090006@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org, Geoffrey M Clemm , w3c-dist-auth-request@w3.org From: Brian Korver Date: Tue, 7 Sep 2004 14:42:28 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 07 Sep 2004 21:42:27.0371 (UTC) FILETIME=[91ADFFB0:01C49523] 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/D054DE86-0116-11D9-918D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8799 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 Sep 2004 21:43:02 +0000 Content-Transfer-Encoding: 7bit On Sep 4, 2004, at 12:58 AM, Julian Reschke wrote: > Brian Korver wrote: > >> Geoff, >> I agree. And I agree with Julian that the "quota" model >> in the spec associates quota with resources, not users, >> which makes it inherently incompatible with the Unix model. >> But I don't think anyone could reasonably argue that the >> spec should be changed to associate quota with users. > > Well, we do. Many quota systems work like that; and if this is > supposed to become the Quota spec supported by the IETF WebDAV mailing > list, it should be compatible with these systems. > > Or on the other hand, removing this part of the spec resolves *that* > issue, and as far as I can tell, only one single vendor is supporting > it anyway. So why not make it a private extension? > >> That would be unDAVlike, unNFSlike, etc. Of course, someone >> could unreasonably argue that position.... ;-) > > I don't get that point. Could you please explain...? We agreed to follow the NFS model and in fact pulled the text essentially unchanged from the NFS RFC. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Sep 7 17:56: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 RAA11103 for ; Tue, 7 Sep 2004 17:56:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4nw7-0005z2-4f; Tue, 07 Sep 2004 21:55:35 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C4nw6-0005yB-AV for w3c-dist-auth@listhub.w3.org; Tue, 07 Sep 2004 21:55:34 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C4nw5-00034U-Ps for w3c-dist-auth@w3.org; Tue, 07 Sep 2004 21:55:34 +0000 Received: (qmail 8184 invoked by uid 65534); 7 Sep 2004 21:55:00 -0000 Received: from p54856A20.dip.t-dialin.net (EHLO [192.168.0.3]) (84.133.106.32) by mail.gmx.net (mp027) with SMTP; 07 Sep 2004 23:55:00 +0200 X-Authenticated: #1915285 Message-ID: <413E2E2F.70209@gmx.de> Date: Tue, 07 Sep 2004 23:54:55 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: w3c-dist-auth@w3.org, Geoffrey M Clemm , w3c-dist-auth-request@w3.org References: <8F0354A5-FDF5-11D8-A93D-000A95AACED2@xythos.com> <413975A0.8090006@gmx.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/413E2E2F.70209@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8800 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 Sep 2004 21:55:35 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > ... > We agreed to follow the NFS model and in fact pulled the > text essentially unchanged from the NFS RFC. So does NFS marshall disk limits trhough quota properties? No. Does NFS make quuto authorable? No. See? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Sep 7 18:31: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 SAA14412 for ; Tue, 7 Sep 2004 18:31:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4oTj-0007cq-3l; Tue, 07 Sep 2004 22:30:19 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C4oTi-0007cK-99 for w3c-dist-auth@listhub.w3.org; Tue, 07 Sep 2004 22:30:18 +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 1C4oTh-0000iU-UR for w3c-dist-auth@w3.org; Tue, 07 Sep 2004 22:30:18 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 15:29:44 -0700 In-Reply-To: <413E2E2F.70209@gmx.de> References: <8F0354A5-FDF5-11D8-A93D-000A95AACED2@xythos.com> <413975A0.8090006@gmx.de> <413E2E2F.70209@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6B6CC53A-011D-11D9-918D-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: WebDAV From: Brian Korver Date: Tue, 7 Sep 2004 15:29:45 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 07 Sep 2004 22:29:44.0296 (UTC) FILETIME=[2C9E6680:01C4952A] 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/6B6CC53A-011D-11D9-918D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8801 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 Sep 2004 22:30:19 +0000 Content-Transfer-Encoding: 7bit I was responding to an earlier suggestion that the model be scrapped in favor of one you proposed not doing. We agreed to the quota-by-resource model, no one has proposed doing any other, so the issue is resolved. But, to answer your questions: Yes, the NFS spec does seem to allow disk limits to me marshalled through the quota properties and certainly doesn't prohibit this ("the server is at liberty to choose"). NFS chooses to define these properties as read-only. -brian briank@xythos.com On Sep 7, 2004, at 2:54 PM, Julian Reschke wrote: > Brian Korver wrote: > > > ... >> We agreed to follow the NFS model and in fact pulled the >> text essentially unchanged from the NFS RFC. > > So does NFS marshall disk limits trhough quota properties? No. Does > NFS make quuto authorable? No. > > See? > > Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Tue Sep 7 18:46: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 SAA15363 for ; Tue, 7 Sep 2004 18:46:13 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4oiB-0002Vi-49; Tue, 07 Sep 2004 22:45:15 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C4oiA-0002V0-Eo for w3c-dist-auth@listhub.w3.org; Tue, 07 Sep 2004 22:45:14 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by bart.w3.org with esmtp (Exim 4.34) id 1C4oi9-00035C-Sa for w3c-dist-auth@w3.org; Tue, 07 Sep 2004 22:45:14 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i87MlVgG011766 for ; Tue, 7 Sep 2004 15:47:31 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Tue, 7 Sep 2004 15:44:42 -0700 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 i87MiPtE020118 for ; Tue, 7 Sep 2004 15:44:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v672) In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <76C38EA8-011F-11D9-B598-000A95DC65E0@apple.com> Content-Transfer-Encoding: quoted-printable From: Jim Luther Date: Tue, 7 Sep 2004 15:44:23 -0700 To: w3c-dist-auth@w3.org X-Mailer: Apple Mail (2.672) Received-SPF: pass (bart.w3.org: domain of luther.j@apple.com designates 17.254.13.22 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/76C38EA8-011F-11D9-B598-000A95DC65E0@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8802 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 Sep 2004 22:45:15 +0000 Content-Transfer-Encoding: quoted-printable After reading all of these arguments, my input is "It's too bad the =20 term "quota" was chosen in the first place." The Mac OS X WebDAV file system does not support Unix-like file system =20= quotas. The Mac OS X WebDAV file system uses the old quota properties* to fill =20= in the f_blocks (total data blocks in filesystem) and f_bfree (free =20 blocks in filesystem) fields returned by statfs(2). In the Mac OS X =20 user interface, those fields become the Capacity, Available, and Used =20= numbers displayed in volume information dialogs (as in "Capacity: =20 100MB" "Available: 49.2 MB" "Used: 50.8 MB on disk"). On Apple's .Mac iDisk WebDAV server, if a client PUT request would =20 cause a user's purchased space to be exceeded, the server returns 507 =20= Insufficient Storage and the WebDAV file system translates that to =20 ENOSPC "No space left on device" (not to EDQUOT "Disc quota exceeded"). For our purposes, the quota properties are considered live properties =20= which cannot be changed by the file system client. So, we're using the old quota properties in a way that compatible with =20= a common industry model... it just isn't the model many on this list =20 are associating with the term "quota". - Jim * DAV: quota and DAV: quotaused as mentioned at =20 On Sep 3, 2004, at 2:31 PM, Geoffrey M Clemm wrote: > > I'm inclined to agree with Julian. =A0A working group standard > should be compatible with common industry models, unless those > models are inherently incompatible. =A0So an informational RFC > seems more appropriate unless that compatibility is achieved. > > Cheers, > Geoff > > > Julian wrote on 09/03/2004 12:39:25 PM: > > > > > Brian Korver wrote: > > > > > Anyone who is going to support this use case should speak up > > > because if no one wants to support your proposed use case then > > > the issue is moot. > > > > So you're saying that the fact that the protocol as specified is > > incompatible with both the NTFS and Unix quota model is moot? > > > > As far as I can tell, the spec as currently published is optimized =20= > for > > one very specific implementation. That's fine, unless people want = to > > make it *the* quota protocol with backing of the WebDAV working =20 > group. > > > > Please either simplify the protocol in a way so that other > > implementations become possible (moving too specific features into > > private extensions), or publish what you have as Informational RFC > > describing what one specific system is supporting today. > > > > Best regards, Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Wed Sep 8 02:06: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 CAA19294 for ; Wed, 8 Sep 2004 02:06:16 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4vZk-000222-A5; Wed, 08 Sep 2004 06:05:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C4vZj-0001zW-IY for w3c-dist-auth@listhub.w3.org; Wed, 08 Sep 2004 06:04:59 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C4vZi-0006R5-8Q for w3c-dist-auth@w3.org; Wed, 08 Sep 2004 06:04:58 +0000 Received: (qmail 14812 invoked by uid 65534); 8 Sep 2004 06:04:25 -0000 Received: from p54856A20.dip.t-dialin.net (EHLO [192.168.0.3]) (84.133.106.32) by mail.gmx.net (mp007) with SMTP; 08 Sep 2004 08:04:25 +0200 X-Authenticated: #1915285 Message-ID: <413EA0DF.5020709@gmx.de> Date: Wed, 08 Sep 2004 08:04:15 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: WebDAV References: <8F0354A5-FDF5-11D8-A93D-000A95AACED2@xythos.com> <413975A0.8090006@gmx.de> <413E2E2F.70209@gmx.de> <6B6CC53A-011D-11D9-918D-000A95AACED2@xythos.com> In-Reply-To: <6B6CC53A-011D-11D9-918D-000A95AACED2@xythos.com> Content-Type: text/plain; charset=us-ascii; 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/413EA0DF.5020709@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8803 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 Sep 2004 06:05:00 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > I was responding to an earlier suggestion that > the model be scrapped in favor of one you proposed > not doing. We agreed to the quota-by-resource model, > no one has proposed doing any other, so the issue > is resolved. I can't remember that anybody agreed on that (pointer, please?). The only p.o.v. that makes sense to me is that the Quota protocol only discusses marshalling, but not the Quota system itself. Thus it should work both with user/group-based and resource-based quota (and other systems that may exist). > But, to answer your questions: Yes, the NFS spec does > seem to allow disk limits to me marshalled through > the quota properties and certainly doesn't prohibit > this ("the server is at liberty to choose"). NFS > chooses to define these properties as read-only. RFC3530, section 5.10: Note that there may be a number of distinct but overlapping sets of files or directories for which a quota_used value is maintained (e.g., "all files with a given owner", "all files with a given group owner", etc.). The server is at liberty to choose any of those sets but should do so in a repeatable way. The rule may be configured per- filesystem or may be "choose the set with the smallest quota". So no, this doesn't apply to disk limits - disk limits are *not* quotas. RFC3530 discusses disk limits in section 5.6: space_free 43 uint64 READ Free disk space in bytes on the filesystem containing this object - this should be the smallest relevant limit. space_total 44 uint64 READ Total disk space in bytes on the filesystem containing this object. space_used 45 uint64 READ Number of filesystem bytes allocated to this object. Also note that RFC3530 distinguishes error conditions for both (section 12): NFS4ERR_DQUOT Resource (quota) hard limit exceeded. The user's resource limit on the server has been exceeded. and NFS4ERR_NOSPC No space left on device. The operation would have caused the server's filesystem to exceed its limit. So again, lett's just do what NFS does: define properties for quota and disk limits, keep the quota definitions such as they are compatible with existing quota systems, distinguish error conditions clearly and keep things read-only. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Sep 8 02:25: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 CAA06629 for ; Wed, 8 Sep 2004 02:25:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C4vs9-0007eY-DW; Wed, 08 Sep 2004 06:24:01 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C4vs8-0007dv-SY for w3c-dist-auth@listhub.w3.org; Wed, 08 Sep 2004 06:24:00 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C4vs8-0001zv-DE for w3c-dist-auth@w3.org; Wed, 08 Sep 2004 06:24:00 +0000 Received: (qmail 5213 invoked by uid 65534); 8 Sep 2004 06:23:27 -0000 Received: from p54856A20.dip.t-dialin.net (EHLO [192.168.0.3]) (84.133.106.32) by mail.gmx.net (mp013) with SMTP; 08 Sep 2004 08:23:27 +0200 X-Authenticated: #1915285 Message-ID: <413EA556.9090400@gmx.de> Date: Wed, 08 Sep 2004 08:23:18 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Luther CC: w3c-dist-auth@w3.org References: <76C38EA8-011F-11D9-B598-000A95DC65E0@apple.com> In-Reply-To: <76C38EA8-011F-11D9-B598-000A95DC65E0@apple.com> Content-Type: text/plain; charset=us-ascii; 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/413EA556.9090400@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8804 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 Sep 2004 06:24:01 +0000 Content-Transfer-Encoding: 7bit Jim Luther wrote: > After reading all of these arguments, my input is "It's too bad the > term "quota" was chosen in the first place." > > The Mac OS X WebDAV file system does not support Unix-like file system > quotas. > > The Mac OS X WebDAV file system uses the old quota properties* to fill > in the f_blocks (total data blocks in filesystem) and f_bfree (free > blocks in filesystem) fields returned by statfs(2). In the Mac OS X > user interface, those fields become the Capacity, Available, and Used > numbers displayed in volume information dialogs (as in "Capacity: > 100MB" "Available: 49.2 MB" "Used: 50.8 MB on disk"). > > On Apple's .Mac iDisk WebDAV server, if a client PUT request would > cause a user's purchased space to be exceeded, the server returns 507 > Insufficient Storage and the WebDAV file system translates that to > ENOSPC "No space left on device" (not to EDQUOT "Disc quota exceeded"). > > For our purposes, the quota properties are considered live properties > which cannot be changed by the file system client. > > So, we're using the old quota properties in a way that compatible with > a common industry model... it just isn't the model many on this list > are associating with the term "quota". > > - Jim Jim, thanks for the information. I think the best (if not only way) to make progress is to focus what parts actually *need* to be standardized. As far as I can tell, people want their clients to display a available/free/used-by-this item indicator in their client. They may or may not care whether this is due to disk limits or quota. They also expect usable error messages. I do *not* see anybody asking for - authorable quota settings (there's only one server implementing that right now) and - there is certainly no demand whatsoever to restrict this to one specific system of computing quota. So let's please focus on what aspects need to be standardized for interoperability, and which don't. Remove those that don't, and I'm sure we can make quick progress. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Sep 8 11:04: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 LAA18618 for ; Wed, 8 Sep 2004 11:04:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C53xn-0000JU-HS; Wed, 08 Sep 2004 15:02:23 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C53xm-0000Iy-Se for w3c-dist-auth@listhub.w3.org; Wed, 08 Sep 2004 15:02:22 +0000 Received: from agminet04.oracle.com ([141.146.126.231]) by bart.w3.org with esmtp (Exim 4.34) id 1C53xm-0000rE-8A for w3c-dist-auth@w3.org; Wed, 08 Sep 2004 15:02:22 +0000 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i88F1X6F000961; Wed, 8 Sep 2004 08:01:33 -0700 Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i88F1Wew007730; Wed, 8 Sep 2004 09:01:32 -0600 Received: from ERICP (dhcp-amer-csvpn-gw1-141-144-64-204.vpn.oracle.com [141.144.64.204]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i88F1VQA007659; Wed, 8 Sep 2004 09:01:32 -0600 Message-ID: <031601c495b4$baef66c0$6901a8c0@ERICP> From: "Eric Sedlar" To: "Julian Reschke" , "Jim Luther" Cc: References: <76C38EA8-011F-11D9-B598-000A95DC65E0@apple.com> <413EA556.9090400@gmx.de> Date: Wed, 8 Sep 2004 08:01:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received-SPF: none (bart.w3.org: domain of eric.sedlar@oracle.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/031601c495b4$baef66c0$6901a8c0@ERICP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8805 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 Sep 2004 15:02:23 +0000 Content-Transfer-Encoding: 7bit I agree with Julian on this. All we want to standardize is the answer to the question: if I store some data at the filesystem indicated by this particular URL, how much data can I store before getting some kind of out of space error? --Eric ----- Original Message ----- From: "Julian Reschke" To: "Jim Luther" Cc: Sent: Tuesday, September 07, 2004 11:23 PM Subject: Re: Quota: another DAV:quota-assigned-bytes question > > Jim Luther wrote: > > > After reading all of these arguments, my input is "It's too bad the > > term "quota" was chosen in the first place." > > > > The Mac OS X WebDAV file system does not support Unix-like file system > > quotas. > > > > The Mac OS X WebDAV file system uses the old quota properties* to fill > > in the f_blocks (total data blocks in filesystem) and f_bfree (free > > blocks in filesystem) fields returned by statfs(2). In the Mac OS X > > user interface, those fields become the Capacity, Available, and Used > > numbers displayed in volume information dialogs (as in "Capacity: > > 100MB" "Available: 49.2 MB" "Used: 50.8 MB on disk"). > > > > On Apple's .Mac iDisk WebDAV server, if a client PUT request would > > cause a user's purchased space to be exceeded, the server returns 507 > > Insufficient Storage and the WebDAV file system translates that to > > ENOSPC "No space left on device" (not to EDQUOT "Disc quota exceeded"). > > > > For our purposes, the quota properties are considered live properties > > which cannot be changed by the file system client. > > > > So, we're using the old quota properties in a way that compatible with > > a common industry model... it just isn't the model many on this list > > are associating with the term "quota". > > > > - Jim > > Jim, > > thanks for the information. > > I think the best (if not only way) to make progress is to focus what > parts actually *need* to be standardized. > > As far as I can tell, people want their clients to display a > available/free/used-by-this item indicator in their client. They may or > may not care whether this is due to disk limits or quota. They also > expect usable error messages. > > I do *not* see anybody asking for > > - authorable quota settings (there's only one server implementing that > right now) and > - there is certainly no demand whatsoever to restrict this to one > specific system of computing quota. > > So let's please focus on what aspects need to be standardized for > interoperability, and which don't. Remove those that don't, and I'm sure > we can make quick progress. > > Best regards, Julian > > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Wed Sep 8 11:39: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 LAA21858 for ; Wed, 8 Sep 2004 11:39:46 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C54We-0002Xg-2z; Wed, 08 Sep 2004 15:38:24 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C54Wd-0002XA-JI for w3c-dist-auth@listhub.w3.org; Wed, 08 Sep 2004 15:38:23 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by bart.w3.org with esmtp (Exim 4.34) id 1C54Wd-0007Xd-5u for w3c-dist-auth@w3.org; Wed, 08 Sep 2004 15:38:23 +0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i88Fbqnt317790 for ; Wed, 8 Sep 2004 11:37:52 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i88Fd54W024252 for ; Wed, 8 Sep 2004 11:39:05 -0400 In-Reply-To: <031601c495b4$baef66c0$6901a8c0@ERICP> 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: Wed, 8 Sep 2004 11:22:30 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF535 | September 3, 2004) at 09/08/2004 11:37:51, Serialize complete at 09/08/2004 11:37:51 Content-Type: multipart/alternative; boundary="=_alternative 0054759485256F09_=" 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/OFEDF0CA11.84CD6679-ON85256F09.00545661-85256F09.0054759B@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8806 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 Sep 2004 15:38:24 +0000 This is a multipart message in MIME format. --=_alternative 0054759485256F09_= Content-Type: text/plain; charset="US-ASCII" I agree with Eric and Julian. Cheers, Geoff Eric wrote on 09/08/2004 11:01:33 AM: > > I agree with Julian on this. All we want to standardize is the answer to > the question: > if I store some data at the filesystem indicated by this particular URL, how > much data > can I store before getting some kind of out of space error? > > --Eric > > ----- Original Message ----- > From: "Julian Reschke" > To: "Jim Luther" > Cc: > Sent: Tuesday, September 07, 2004 11:23 PM > Subject: Re: Quota: another DAV:quota-assigned-bytes question > > > > > > Jim Luther wrote: > > > > > After reading all of these arguments, my input is "It's too bad the > > > term "quota" was chosen in the first place." > > > > > > The Mac OS X WebDAV file system does not support Unix-like file system > > > quotas. > > > > > > The Mac OS X WebDAV file system uses the old quota properties* to fill > > > in the f_blocks (total data blocks in filesystem) and f_bfree (free > > > blocks in filesystem) fields returned by statfs(2). In the Mac OS X > > > user interface, those fields become the Capacity, Available, and Used > > > numbers displayed in volume information dialogs (as in "Capacity: > > > 100MB" "Available: 49.2 MB" "Used: 50.8 MB on disk"). > > > > > > On Apple's .Mac iDisk WebDAV server, if a client PUT request would > > > cause a user's purchased space to be exceeded, the server returns 507 > > > Insufficient Storage and the WebDAV file system translates that to > > > ENOSPC "No space left on device" (not to EDQUOT "Disc quota exceeded"). > > > > > > For our purposes, the quota properties are considered live properties > > > which cannot be changed by the file system client. > > > > > > So, we're using the old quota properties in a way that compatible with > > > a common industry model... it just isn't the model many on this list > > > are associating with the term "quota". > > > > > > - Jim > > > > Jim, > > > > thanks for the information. > > > > I think the best (if not only way) to make progress is to focus what > > parts actually *need* to be standardized. > > > > As far as I can tell, people want their clients to display a > > available/free/used-by-this item indicator in their client. They may or > > may not care whether this is due to disk limits or quota. They also > > expect usable error messages. > > > > I do *not* see anybody asking for > > > > - authorable quota settings (there's only one server implementing that > > right now) and > > - there is certainly no demand whatsoever to restrict this to one > > specific system of computing quota. > > > > So let's please focus on what aspects need to be standardized for > > interoperability, and which don't. Remove those that don't, and I'm sure > > we can make quick progress. > > > > Best regards, Julian > > > > > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > > --=_alternative 0054759485256F09_= Content-Type: text/html; charset="US-ASCII"
I agree with Eric and Julian.

Cheers,
Geoff

Eric wrote on 09/08/2004 11:01:33 AM:

>
> I agree with Julian on this.  All we want to standardize is the answer to
> the question:
> if I store some data at the filesystem indicated by this particular URL, how
> much data
> can I store before getting some kind of out of space error?
>
> --Eric
>
> ----- Original Message -----
> From: "Julian Reschke" <julian.reschke@gmx.de>
> To: "Jim Luther" <luther.j@apple.com>
> Cc: <w3c-dist-auth@w3.org>
> Sent: Tuesday, September 07, 2004 11:23 PM
> Subject: Re: Quota: another DAV:quota-assigned-bytes question
>
>
> >
> > Jim Luther wrote:
> >
> > > After reading all of these arguments, my input is "It's too bad the
> > > term "quota" was chosen in the first place."
> > >
> > > The Mac OS X WebDAV file system does not support Unix-like file system
> > > quotas.
> > >
> > > The Mac OS X WebDAV file system uses the old quota properties* to fill
> > > in the f_blocks (total data blocks in filesystem) and f_bfree (free
> > > blocks in filesystem) fields returned by statfs(2).  In the Mac OS X
> > > user interface, those fields become the Capacity, Available, and Used
> > > numbers displayed in volume information dialogs (as in "Capacity:
> > > 100MB" "Available: 49.2 MB" "Used: 50.8 MB on disk").
> > >
> > > On Apple's .Mac iDisk WebDAV server, if a client PUT request would
> > > cause a user's purchased space to be exceeded, the server returns 507
> > > Insufficient Storage and the WebDAV file system translates that to
> > > ENOSPC "No space left on device" (not to EDQUOT "Disc quota exceeded").
> > >
> > > For our purposes, the quota properties are considered live properties
> > > which cannot be changed by the file system client.
> > >
> > > So, we're using the old quota properties in a way that compatible with
> > > a common industry model... it just isn't the model many on this list
> > > are associating with the term "quota".
> > >
> > > - Jim
> >
> > Jim,
> >
> > thanks for the information.
> >
> > I think the best (if not only way) to make progress is to focus what
> > parts actually *need* to be standardized.
> >
> > As far as I can tell, people want their clients to display a
> > available/free/used-by-this item indicator in their client. They may or
> > may not care whether this is due to disk limits or quota. They also
> > expect usable error messages.
> >
> > I do *not* see anybody asking for
> >
> > - authorable quota settings (there's only one server implementing that
> > right now) and
> > - there is certainly no demand whatsoever to restrict this to one
> > specific system of computing quota.
> >
> > So let's please focus on what aspects need to be standardized for
> > interoperability, and which don't. Remove those that don't, and I'm sure
> > we can make quick progress.
> >
> > Best regards, Julian
> >
> >
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
> >
>
>
>
--=_alternative 0054759485256F09_=-- From w3c-dist-auth-request@w3.org Wed Sep 8 12:30: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 MAA25623 for ; Wed, 8 Sep 2004 12:30:10 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C55JU-0002yF-Kn; Wed, 08 Sep 2004 16:28:52 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C55JU-0002xh-1z for w3c-dist-auth@listhub.w3.org; Wed, 08 Sep 2004 16:28:52 +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 1C55JT-00015Y-M9 for w3c-dist-auth@w3.org; Wed, 08 Sep 2004 16:28:51 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Sep 2004 09:28:16 -0700 In-Reply-To: <413EA0DF.5020709@gmx.de> References: <8F0354A5-FDF5-11D8-A93D-000A95AACED2@xythos.com> <413975A0.8090006@gmx.de> <413E2E2F.70209@gmx.de> <6B6CC53A-011D-11D9-918D-000A95AACED2@xythos.com> <413EA0DF.5020709@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1641523F-01B4-11D9-918D-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: WebDAV From: Brian Korver Date: Wed, 8 Sep 2004 09:28:16 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 08 Sep 2004 16:28:16.0358 (UTC) FILETIME=[D8037060:01C495C0] 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/1641523F-01B4-11D9-918D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8807 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 Sep 2004 16:28:52 +0000 Content-Transfer-Encoding: 7bit On Sep 7, 2004, at 11:04 PM, Julian Reschke wrote: > Brian Korver wrote: > >> I was responding to an earlier suggestion that >> the model be scrapped in favor of one you proposed >> not doing. We agreed to the quota-by-resource model, >> no one has proposed doing any other, so the issue >> is resolved. > > I can't remember that anybody agreed on that (pointer, please?). The > only p.o.v. that makes sense to me is that the Quota protocol only > discusses marshalling, but not the Quota system itself. Thus it should > work both with user/group-based and resource-based quota (and other > systems that may exist). > >> But, to answer your questions: Yes, the NFS spec does >> seem to allow disk limits to me marshalled through >> the quota properties and certainly doesn't prohibit >> this ("the server is at liberty to choose"). NFS >> chooses to define these properties as read-only. > > RFC3530, section 5.10: > > Note that there may be a number of distinct but overlapping > sets of files or directories for which a quota_used value is > maintained (e.g., "all files with a given owner", "all files > with a given group owner", etc.). > > The server is at liberty to choose any of those sets but > should > do so in a repeatable way. The rule may be configured per- > filesystem or may be "choose the set with the smallest quota". > > So no, this doesn't apply to disk limits - disk limits are *not* > quotas. The text says otherwise: The server can choose whatever set of resources it wants to compute quota. It puts no restrictions on that. Period. > RFC3530 discusses disk limits in section 5.6: > > > space_free 43 uint64 READ Free disk space in > bytes on the > filesystem > containing this > object - this > should > be the smallest > relevant limit. > > space_total 44 uint64 READ Total disk space in > bytes on the > filesystem > containing this > object. > > space_used 45 uint64 READ Number of > filesystem > bytes allocated to > this object. > > Also note that RFC3530 distinguishes error conditions for both > (section 12): > > NFS4ERR_DQUOT Resource (quota) hard limit exceeded. The > user's resource limit on the server has been > exceeded. > > and > > NFS4ERR_NOSPC No space left on device. The operation would > have caused the server's filesystem to exceed > its limit. > > > So again, lett's just do what NFS does: define properties for quota > and disk limits, keep the quota definitions such as they are > compatible with existing quota systems, distinguish error conditions > clearly and keep things read-only. That all sounds good, but you ascribe properties to NFS that it doesn't have (ex: compatible with [all] existing quota systems). Personally I don't have any issue with adding another error code. I know in practice they'll be treated as semantically equivalent, so it seems gratuitous, but let's > > Best regards, Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Wed Sep 8 15:48: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 PAA10641 for ; Wed, 8 Sep 2004 15:48:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C58P4-00089Z-Bk; Wed, 08 Sep 2004 19:46:50 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C58P3-00088y-NT for w3c-dist-auth@listhub.w3.org; Wed, 08 Sep 2004 19:46:49 +0000 Received: from agminet04.oracle.com ([141.146.126.231]) by bart.w3.org with esmtp (Exim 4.34) id 1C58P3-00072N-7m for w3c-dist-auth@w3.org; Wed, 08 Sep 2004 19:46:49 +0000 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.191.11]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i88JkHhP015047 for ; Wed, 8 Sep 2004 12:46:18 -0700 Received: from rgmgw2.us.oracle.com (localhost [127.0.0.1]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i88JkHQb028325 for ; Wed, 8 Sep 2004 13:46:17 -0600 Received: from rmurthylap (dhcp-4op7-4op8-west-130-35-170-188.us.oracle.com [130.35.170.188]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i88JkG1Y028294 for ; Wed, 8 Sep 2004 13:46:17 -0600 Message-ID: <009901c495dc$80ed0fe0$bcaa2382@us.oracle.com> From: "Ravi Murthy" To: Date: Wed, 8 Sep 2004 12:46:15 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0096_01C495A1.D4468080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Received-SPF: none (bart.w3.org: domain of ravi.murthy@oracle.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: behavior of dav:inherited-acl-set X-Archived-At: http://www.w3.org/mid/009901c495dc$80ed0fe0$bcaa2382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8808 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 Sep 2004 19:46:50 +0000 This is a multi-part message in MIME format. ------=_NextPart_000_0096_01C495A1.D4468080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does the property apply recursively ? i.e. if a = resource R1 specifies R2 as part of its , then in = addition to the ACL on R2 (as specified by DAV:acl property), does the = property of R2 *also* apply in determining the = privilege on R1 ? The RFC is not very clear on this point. -- Excerpt from RFC 3744 5.7 DAV:inherited-acl-set This protected property contains a set of URLs that identify other = resources that also control the access to this resource. To have a = privilege on a resource, not only must the ACL on that resource = (specified in the DAV:acl property of that resource) grant the = privilege, but so must the ACL of each resource identified in the = DAV:inherited-acl-set property of that resource. Effectively, the = privileges granted by the current ACL are ANDed with the privileges = granted by each inherited ACL.=20 -- End Excerpt Thanks. - Ravi ------=_NextPart_000_0096_01C495A1.D4468080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does the <dav:inherited-acl-set> = property=20 apply recursively ? i.e. if a resource R1 specifies R2 as part of its=20 <dav:inherited-acl-set>, then in addition to the ACL on R2 (as = specified=20 by DAV:acl property), does the <dav:inherited-acl-set> property of = R2=20 *also* apply in determining the privilege on R1 ? The RFC is not very = clear on=20 this point.
 
-- Excerpt from RFC 3744

5.7 DAV:inherited-acl-set

This protected property contains a set of URLs that identify other = resources=20 that also control the access to this resource. To have a privilege on a=20 resource, not only must the ACL on that resource (specified in the = DAV:acl=20 property of that resource) grant the privilege, but so must the ACL of = each=20 resource identified in the DAV:inherited-acl-set property of that = resource.=20 Effectively, the privileges granted by the current ACL are ANDed with = the=20 privileges granted by each inherited ACL.

-- End Excerpt

Thanks.

- Ravi

 

------=_NextPart_000_0096_01C495A1.D4468080-- From w3c-dist-auth-request@w3.org Wed Sep 8 18:09: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 SAA26485 for ; Wed, 8 Sep 2004 18:09:24 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C5Abr-00025H-Bg; Wed, 08 Sep 2004 22:08:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C5Abq-00024h-KU for w3c-dist-auth@listhub.w3.org; Wed, 08 Sep 2004 22:08:10 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C5Abp-0003Lc-7o for w3c-dist-auth@w3.org; Wed, 08 Sep 2004 22:08:09 +0000 Received: (qmail 17663 invoked by uid 65534); 8 Sep 2004 22:07:38 -0000 Received: from pD9E5121F.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.18.31) by mail.gmx.net (mp025) with SMTP; 09 Sep 2004 00:07:38 +0200 X-Authenticated: #1915285 Message-ID: <413F82A4.7000701@gmx.de> Date: Thu, 09 Sep 2004 00:07:32 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: WebDAV References: <8F0354A5-FDF5-11D8-A93D-000A95AACED2@xythos.com> <413975A0.8090006@gmx.de> <413E2E2F.70209@gmx.de> <6B6CC53A-011D-11D9-918D-000A95AACED2@xythos.com> <413EA0DF.5020709@gmx.de> <1641523F-01B4-11D9-918D-000A95AACED2@xythos.com> In-Reply-To: <1641523F-01B4-11D9-918D-000A95AACED2@xythos.com> Content-Type: text/plain; charset=us-ascii; 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/413F82A4.7000701@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8809 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 Sep 2004 22:08:11 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: >> RFC3530, section 5.10: >> >> Note that there may be a number of distinct but overlapping >> sets of files or directories for which a quota_used value is >> maintained (e.g., "all files with a given owner", "all files >> with a given group owner", etc.). >> >> The server is at liberty to choose any of those sets but should >> do so in a repeatable way. The rule may be configured per- >> filesystem or may be "choose the set with the smallest quota". >> >> So no, this doesn't apply to disk limits - disk limits are *not* quotas. > > The text says otherwise: The server can choose whatever set of > resources it wants to compute quota. It puts no restrictions > on that. Period. Brian, this is a paragraph from a section that talks about quota and nothing else, so of course it talks only about quota. > That all sounds good, but you ascribe properties to NFS that it > doesn't have (ex: compatible with [all] existing quota systems). Ok. Which one is it incompatible with? > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Sep 8 18: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 SAA27865 for ; Wed, 8 Sep 2004 18:19:39 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C5Alu-0006Ev-4t; Wed, 08 Sep 2004 22:18:34 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C5Alp-0006Cd-7G for w3c-dist-auth@listhub.w3.org; Wed, 08 Sep 2004 22:18:29 +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 1C5Alo-0007bH-Qz for w3c-dist-auth@w3.org; Wed, 08 Sep 2004 22:18:28 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Sep 2004 15:17:55 -0700 In-Reply-To: <413F82A4.7000701@gmx.de> References: <8F0354A5-FDF5-11D8-A93D-000A95AACED2@xythos.com> <413975A0.8090006@gmx.de> <413E2E2F.70209@gmx.de> <6B6CC53A-011D-11D9-918D-000A95AACED2@xythos.com> <413EA0DF.5020709@gmx.de> <1641523F-01B4-11D9-918D-000A95AACED2@xythos.com> <413F82A4.7000701@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDAV From: Brian Korver Date: Wed, 8 Sep 2004 15:17:55 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 08 Sep 2004 22:17:55.0374 (UTC) FILETIME=[B07B3CE0:01C495F1] 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/EEC1749A-01E4-11D9-918D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8810 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 Sep 2004 22:18:34 +0000 Content-Transfer-Encoding: 7bit On Sep 8, 2004, at 3:07 PM, Julian Reschke wrote: > Brian Korver wrote: >>> RFC3530, section 5.10: >>> >>> Note that there may be a number of distinct but overlapping >>> sets of files or directories for which a quota_used value is >>> maintained (e.g., "all files with a given owner", "all files >>> with a given group owner", etc.). >>> >>> The server is at liberty to choose any of those sets but >>> should >>> do so in a repeatable way. The rule may be configured per- >>> filesystem or may be "choose the set with the smallest >>> quota". >>> >>> So no, this doesn't apply to disk limits - disk limits are *not* >>> quotas. > > >> The text says otherwise: The server can choose whatever set of >> resources it wants to compute quota. It puts no restrictions >> on that. Period. > > Brian, this is a paragraph from a section that talks about quota and > nothing else, so of course it talks only about quota. Precisely, and it states the server can choose how it computes quota. Again, not only does the spec place no restrictions on how the server chooses to compute quota, it explicitly states there are no restrictions. > >> That all sounds good, but you ascribe properties to NFS that it >> doesn't have (ex: compatible with [all] existing quota systems). > > Ok. Which one is it incompatible with? I thought you said it wasn't compatible with authorable quota systems.... ;-) > >> ... > > Best regards, Julian > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Thu Sep 9 00:37: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 AAA00848 for ; Thu, 9 Sep 2004 00:37:37 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C5GfH-0003OX-19; Thu, 09 Sep 2004 04:36:07 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C5GfG-0003O1-DG for w3c-dist-auth@listhub.w3.org; Thu, 09 Sep 2004 04:36:06 +0000 Received: from agminet02.oracle.com ([141.146.126.229]) by bart.w3.org with esmtp (Exim 4.34) id 1C5GfG-0002vX-0K for w3c-dist-auth@w3.org; Thu, 09 Sep 2004 04:36:06 +0000 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.191.11]) by agminet02.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i894ZYkY006713 for ; Wed, 8 Sep 2004 21:35:35 -0700 Received: from rgmgw2.us.oracle.com (localhost [127.0.0.1]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i894ZYd6028535 for ; Wed, 8 Sep 2004 22:35:34 -0600 Received: from esedlarlap1 (dhcp-4op7-4op8-west-130-35-170-111.us.oracle.com [130.35.170.111]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i894ZY5k028530 for ; Wed, 8 Sep 2004 22:35:34 -0600 Message-ID: <01d201c49626$6ed3bb70$d15efea9@us.oracle.com> From: "Eric Sedlar" To: References: <009901c495dc$80ed0fe0$bcaa2382@us.oracle.com> Date: Wed, 8 Sep 2004 21:35:28 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CF_01C495EB.C24EBDD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received-SPF: none (bart.w3.org: domain of eric.sedlar@oracle.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: behavior of dav:inherited-acl-set X-Archived-At: http://www.w3.org/mid/01d201c49626$6ed3bb70$d15efea9@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8811 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 Sep 2004 04:36:07 +0000 This is a multi-part message in MIME format. ------=_NextPart_000_01CF_01C495EB.C24EBDD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No, if you read the spec carefully, inherited-acl-set only inherits the = ACL property, not any other access-control related properties (like = inherited-acl-set). In section 5.7, the text says: " To have a privilege on a resource, not only must the ACL on that = resource (specified in the DAV:acl property of that resource) grant the = privilege, but so must the ACL of each resource identified in the = DAV:inherited-acl-set property of that resource." ----- Original Message -----=20 From: Ravi Murthy=20 To: w3c-dist-auth@w3.org=20 Sent: Wednesday, September 08, 2004 12:46 PM Subject: behavior of dav:inherited-acl-set Does the property apply recursively ? i.e. if = a resource R1 specifies R2 as part of its , then = in addition to the ACL on R2 (as specified by DAV:acl property), does = the property of R2 *also* apply in determining = the privilege on R1 ? The RFC is not very clear on this point. -- Excerpt from RFC 3744 5.7 DAV:inherited-acl-set This protected property contains a set of URLs that identify other = resources that also control the access to this resource. To have a = privilege on a resource, not only must the ACL on that resource = (specified in the DAV:acl property of that resource) grant the = privilege, but so must the ACL of each resource identified in the = DAV:inherited-acl-set property of that resource. Effectively, the = privileges granted by the current ACL are ANDed with the privileges = granted by each inherited ACL.=20 -- End Excerpt Thanks. - Ravi ------=_NextPart_000_01CF_01C495EB.C24EBDD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
No, if you read the spec carefully,=20 inherited-acl-set only inherits the ACL property, not any other = access-control=20 related properties (like inherited-acl-set).  In section 5.7, the = text=20 says:
 
" To have a privilege on a resource, not only must the = ACL on that=20 resource (specified in the DAV:acl property of that resource) grant=20 the privilege, but so must the ACL of each resource identified in = the=20 DAV:inherited-acl-set property of that resource."
----- Original Message -----
From:=20 Ravi=20 Murthy
Sent: Wednesday, September 08, = 2004 12:46=20 PM
Subject: behavior of=20 dav:inherited-acl-set

Does the = <dav:inherited-acl-set> property=20 apply recursively ? i.e. if a resource R1 specifies R2 as part of its=20 <dav:inherited-acl-set>, then in addition to the ACL on R2 (as = specified=20 by DAV:acl property), does the <dav:inherited-acl-set> property = of R2=20 *also* apply in determining the privilege on R1 ? The RFC is not very = clear on=20 this point.
 
-- Excerpt from RFC 3744

5.7 DAV:inherited-acl-set

This protected property contains a set of URLs that identify other=20 resources that also control the access to this resource. To have a = privilege=20 on a resource, not only must the ACL on that resource (specified in = the=20 DAV:acl property of that resource) grant the privilege, but so must = the ACL of=20 each resource identified in the DAV:inherited-acl-set property of that = resource. Effectively, the privileges granted by the current ACL are = ANDed=20 with the privileges granted by each inherited ACL.

-- End Excerpt

Thanks.

- Ravi

 

------=_NextPart_000_01CF_01C495EB.C24EBDD0-- From w3c-dist-auth-request@w3.org Thu Sep 9 03:43: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 DAA25571 for ; Thu, 9 Sep 2004 03:43:06 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C5JZQ-0002xS-1a; Thu, 09 Sep 2004 07:42:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C5JZP-0002wr-4w for w3c-dist-auth@listhub.w3.org; Thu, 09 Sep 2004 07:42:15 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C5JZN-0002KS-Nf for w3c-dist-auth@w3.org; Thu, 09 Sep 2004 07:42:13 +0000 Received: (qmail 32428 invoked by uid 65534); 9 Sep 2004 07:41:42 -0000 Received: from pD9E519A2.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.25.162) by mail.gmx.net (mp009) with SMTP; 09 Sep 2004 09:41:42 +0200 X-Authenticated: #1915285 Message-ID: <41400933.8050500@gmx.de> Date: Thu, 09 Sep 2004 09:41:39 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: WebDAV References: <8F0354A5-FDF5-11D8-A93D-000A95AACED2@xythos.com> <413975A0.8090006@gmx.de> <413E2E2F.70209@gmx.de> <6B6CC53A-011D-11D9-918D-000A95AACED2@xythos.com> <413EA0DF.5020709@gmx.de> <1641523F-01B4-11D9-918D-000A95AACED2@xythos.com> <413F82A4.7000701@gmx.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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: Quota: another DAV:quota-assigned-bytes question X-Archived-At: http://www.w3.org/mid/41400933.8050500@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8812 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 Sep 2004 07:42:16 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > .. > Precisely, and it states the server can choose how it computes > quota. Again, not only does the spec place no restrictions on > how the server chooses to compute quota, it explicitly states > there are no restrictions. OK, let's just agree that we disagree. I don't think that any further dicussion makes sense. >>> That all sounds good, but you ascribe properties to NFS that it >>> doesn't have (ex: compatible with [all] existing quota systems). >> >> >> Ok. Which one is it incompatible with? > > > I thought you said it wasn't compatible with authorable quota > systems.... ;-) No, I didn't say that. What I said is that it doesn't *support* it. Obviously you can have authorable quota on a system that supports NFS. You just can't use NFS (at least not this part of the protocol; maybe there's something else) to *do* it. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 9 16:12: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 QAA20826 for ; Thu, 9 Sep 2004 16:12:25 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C5VGj-0004MV-Uk; Thu, 09 Sep 2004 20:11:45 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C5VGj-0004Lw-8y for w3c-dist-auth@listhub.w3.org; Thu, 09 Sep 2004 20:11:45 +0000 Received: from intmail.sequoianet.com ([63.97.219.13]) by bart.w3.org with esmtp (Exim 4.34) id 1C5VGi-0007dr-ST for w3c-dist-auth@w3.org; Thu, 09 Sep 2004 20:11:44 +0000 Received: from seqhqemailbh.seqnt.com ([63.97.219.16]) by intmail.sequoianet.com with InterScan Messaging Security Suite; Thu, 09 Sep 2004 16:22:00 -0400 Received: from lansingemail.seqnt.com ([172.18.2.73]) by seqhqemailbh.seqnt.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Sep 2004 16:09:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Sep 2004 16:09:09 -0400 Message-ID: <0FD9D979B9535D4890AE309799B6D1E59DA065@lansingemail.seqnt.com> Thread-Topic: Analyzing WebDAV security Thread-Index: AcSPa+tgN3IobrebTyiTXvS5u6ZeMwHPRj5A From: "Lachniet, Mark" To: X-OriginalArrivalTime: 09 Sep 2004 20:09:09.0751 (UTC) FILETIME=[DE107870:01C496A8] Received-SPF: none (bart.w3.org: domain of mlachniet@sequoianet.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Analyzing WebDAV security X-Archived-At: http://www.w3.org/mid/0FD9D979B9535D4890AE309799B6D1E59DA065@lansingemail.seqnt.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8813 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 Sep 2004 20:11:45 +0000 Content-Transfer-Encoding: quoted-printable Hello again, sorry for the resend but I didn't get any responses. I figured I'd give one more try before giving up. =20 > Hello all, >=20 > Please forgive me if my questions have been covered in other=20 > threads, but I have searched the archives and not found what=20 > I am looking for. There was one reference at=20 > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0 > 032.html that got somewhat close, but not close enough. I=20 > also tried posting to a penetration testing listserve with no results. >=20 > In my work, I do a lot of security assessments of web sites. =20 > Many of them have WebDAV set up, and most of them are=20 > moderately well secured. However, I'm not confident that=20 > security analysts are really doing a good job of assessing=20 > WebDAV, and I want to make sure I'm doing all I can. >=20 > I'm not really interested in talking about SSL and=20 > authentication protocols like Digest, etc. - that's pretty=20 > well covered in other places - I am talking just within=20 > WebDAV itself. I'm also not interested in well known and=20 > publicised flaws that have been fixed by patches. >=20 > For example, when I come across a web site with WebDAV=20 > enabled for the public, I have typically been opening up a=20 > session with Cadaver to see if I can get into anything I'm=20 > not supposed to. Inevitably, I can log in, 'cd' to=20 > directories that I know exist on the server, and that's about=20 > it. I cannot usually even see any files, collections, or=20 > create directories or write files. I realize this is=20 > probably not the best way to test, but alas I am unaware of=20 > what else to do. >=20 > So, I guess my questions are: >=20 > 1) Is there any kind of formal WebDAV security checklists,=20 > software or scripts to check settings? Most scanners (e.g.=20 > Nessus) will note the existence of it, but won't do much else=20 > that I am aware of. >=20 > 2) Is there any software to enumerate or brute-force=20 > directory space? Perhaps looking for directories you aren't=20 > supposed to see? >=20 > 3) Is there any software to enumerate or brute force=20 > authentication credentials easily? >=20 > 4) What other types of things should I be doing to help my=20 > clients be more secure? >=20 > Thank you in advance for your help and patience. >=20 > Mark Lachniet >=20 From w3c-dist-auth-request@w3.org Fri Sep 10 01:54: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 BAA11059 for ; Fri, 10 Sep 2004 01:54:46 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C5eMN-0007ca-LY; Fri, 10 Sep 2004 05:54:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C5eMM-0007aw-Sw for w3c-dist-auth@listhub.w3.org; Fri, 10 Sep 2004 05:54:10 +0000 Received: from chandgate.mahindrabt.com ([202.75.195.52]) by lisa.w3.org with esmtp (Exim 4.34) id 1C5eMK-0003Dn-Rh for w3c-dist-auth@w3.org; Fri, 10 Sep 2004 05:54:09 +0000 Received: from interscan (imss1.chand.mahindrabt.com [10.3.0.65]) by chandgate.mahindrabt.com (8.12.10/8.12.10) with ESMTP id i8A61EJ5027482 for ; Fri, 10 Sep 2004 11:31:14 +0530 Received: from intranet.chand.mahindrabt.com ([10.3.0.2]) by interscan with InterScan Messaging Security Suite; Fri, 10 Sep 2004 11:28:38 +0530 Received: from british-s9m83vo ([10.3.0.150])by intranet.chand.mahindrabt.com (8.12.10/8.12.10) with ESMTP id i8A60E8L010740for ; Fri, 10 Sep 2004 11:30:14 +0530 Received: from dscp0744 ([10.3.8.254]) by british-s9m83vo with InterScan Messaging Security Suite; Fri, 10 Sep 2004 11:29:43 +0530 Message-ID: <01e501c496fc$63e93790$fe08030a@mahindrabt.com> From: "Varun Pande" To: References: <013a01c493f3$a080d430$9708030a@mahindrabt.com> Date: Fri, 10 Sep 2004 11:37:02 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E2_01C4972A.7D9CB8A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Received-SPF: none (lisa.w3.org: domain of varunp@mahindrabt.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Platform for WebDav Development X-Archived-At: http://www.w3.org/mid/01e501c496fc$63e93790$fe08030a@mahindrabt.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8814 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 Sep 2004 05:54:11 +0000 This is a multi-part message in MIME format. ------=_NextPart_000_01E2_01C4972A.7D9CB8A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have been really struggling to find out how to carry out some basic tasks= in Webdav development, having a rdbms background Some besic queries if anyone can help me out with code samples. 1) How to connect to exchange server database? 2) How to add microsoft outlook tasks for particular user, so that if he= opens his mailbox he can see the list of tasks? tasks are retrieved from= an oracle table I am also unable to find any documentation and code samples on microsoft= outlook tasks as far as urn schemas and properties are concerned. Waiting for some really helpful response from the group. Thanks & Regards -Varun ********************************************************* Disclaimer: =0D This message (including any attachments) contains=0D confidential information intended for a specific=0D individual and purpose, and is protected by law.=0D If you are not the intended recipient, you should=0D delete this message and are hereby notified that=0D any disclosure, copying, or distribution of this message, or the taking of any action based on it,=0D is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_01E2_01C4972A.7D9CB8A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I have been really struggling to find out= how to=0D carry out some basic tasks in Webdav development, having a rdbms=0D background
 
Some besic queries if anyone can help me= out with=0D code samples.
 
1) How to connect to exchange server=0D database?
 
2) How to add microsoft outlook tasks for= =0D particular user, so that if he opens his mailbox he can see the list of= tasks?=0D tasks are retrieved from an oracle table
 
I am also unable to find any documentation= and code=0D samples on microsoft outlook tasks as far as urn schemas and properties are= =0D concerned.
 
Waiting for some really helpful= response from=0D the group.
 
 Thanks & Regards
-Varun
 
 
 
*********************************************************
Dis= claimer:

This message (including any attachments) contains=
confidential information intended for a specific
individual and= purpose, and is protected by law.
If you are not the intended= recipient, you should
delete this message and are hereby notified that=
any disclosure, copying, or distribution of this
message, or the= taking of any action based on it,
is strictly= prohibited.

*******************************************************= **
Visit us at= http://www.mahindrabt.com



------=_NextPart_000_01E2_01C4972A.7D9CB8A0-- From w3c-dist-auth-request@w3.org Fri Sep 10 12:10: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 MAA09923 for ; Fri, 10 Sep 2004 12:10:17 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C5nxz-0005KO-PU; Fri, 10 Sep 2004 16:09:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C5nxz-0005Js-2W for w3c-dist-auth@listhub.w3.org; Fri, 10 Sep 2004 16:09:39 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1C5nxx-0005nK-L3 for w3c-dist-auth@w3.org; Fri, 10 Sep 2004 16:09:37 +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 i8AG8lpp006140 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 10 Sep 2004 09:08:49 -0700 In-Reply-To: <01e501c496fc$63e93790$fe08030a@mahindrabt.com> References: <013a01c493f3$a080d430$9708030a@mahindrabt.com> <01e501c496fc$63e93790$fe08030a@mahindrabt.com> 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, 10 Sep 2004 09:08:40 -0700 To: "Varun Pande" X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (lisa.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Platform for WebDav Development X-Archived-At: http://www.w3.org/mid/AE04F584-0343-11D9-9C6B-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8815 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 Sep 2004 16:09:39 +0000 Content-Transfer-Encoding: 7bit Hi Varun, The mailing list you posted to discusses the WebDAV protocol standard, and issues related to IETF protocol specifications. It does not discuss development of WebDAV tools. It seems like you're looking for specific Microsoft developer assistance (because Exchange extended WebDAV in several non-standard ways, including the task schema) so I'd suggest you seek out a Microsoft-specific or Exchange-specific forum. Lisa On Sep 9, 2004, at 11:07 PM, Varun Pande wrote: > > Hi, > I have been really struggling to find out how to carry out some basic > tasks in Webdav development, having a rdbms background > > Some besic queries if anyone can help me out with code samples. > > 1) How to connect to exchange server database? > > 2) How to add microsoft outlook tasks for particular user, so that if > he opens his mailbox he can see the list of tasks? tasks are retrieved > from an oracle table > > I am also unable to find any documentation and code samples on > microsoft outlook tasks as far as urn schemas and properties are > concerned. > > Waiting for some really helpful response from the group. > > Thanks & Regards > -Varun > > > > > > ********************************************************* > Disclaimer: > > This message (including any attachments) contains > confidential information intended for a specific > individual and purpose, and is protected by law. > If you are not the intended recipient, you should > delete this message and are hereby notified that > any disclosure, copying, or distribution of this > message, or the taking of any action based on it, > is strictly prohibited. > > ********************************************************* > Visit us at http://www.mahindrabt.com > > From w3c-dist-auth-request@w3.org Sat Sep 11 12:36: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 MAA26339 for ; Sat, 11 Sep 2004 12:36:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6AqT-0001ZB-5r; Sat, 11 Sep 2004 16:35:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C6AqS-0001YZ-E6 for w3c-dist-auth@listhub.w3.org; Sat, 11 Sep 2004 16:35:24 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C6AqQ-0007vS-Hf for w3c-dist-auth@w3.org; Sat, 11 Sep 2004 16:35:23 +0000 Received: (qmail 32148 invoked by uid 65534); 11 Sep 2004 16:34:48 -0000 Received: from p54856894.dip.t-dialin.net (EHLO [192.168.0.3]) (84.133.104.148) by mail.gmx.net (mp023) with SMTP; 11 Sep 2004 18:34:48 +0200 X-Authenticated: #1915285 Message-ID: <41432917.7030900@gmx.de> Date: Sat, 11 Sep 2004 18:34:31 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Issues with rfc2518bis-06 (part 1) X-Archived-At: http://www.w3.org/mid/41432917.7030900@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8816 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, 11 Sep 2004 16:35:25 +0000 Content-Transfer-Encoding: 8bit Hi. Below is a list of issues I raised against drafts 02, 03, and 04 which IMHO have not been adequately addressed in the latest draft -06 (see [1] through [6] for the original messages). C02-14) Section 8.11, The Effect of Locks on Properties and Collections "This means that if a collection is locked, its lock-token is required in all these cases: - DELETE a collection's direct internal member - MOVE a member out of the collection - MOVE a member into the collection, unless it overwrites a pre-existing member" I think the latter is not really consistent with RFC3253. [In general I'd like to have the latest GULP as normative appendix, and remove some of the prose about lock behaviour from the various sections; I think this is also we agreed upon in January] C02-10) Section 8.2.2 (...) Also: the example for propfind/allprop is missing. Why was it removed? C02-18) Section 9.1 I'd like to see the rational for the "extend" production. 03-C03 4.4: “Note that the use of a new top-level URI identifier as a namespace is considered by many to be a bad thing…” [as of draft 04 this now reads: "Note that ”DAV:“ is a top-level URI identifier that was defined solely to provide a namespace for WebDAV XML elements and property names. This practice is discouraged in part because registration of top-level URI identifiers is difficult. "DAV:" was defined as the WebDAV namespace before standard best practices emerged, and this namespace is kept and still used because of significant existing deployments, but this should not be emulated. "] Rewrite as: “Note that both defining a new URI scheme just for the purpose of identifying protocol elements, and using just the scheme name as a namespace name is to be considered a bad practice, and should not be copied”. [draft 05 now says...] Note that “DAV:” is a scheme name defined solely to provide a namespace for WebDAV XML elements and property names. This practice is discouraged in part because registration of new scheme names is difficult. "DAV:" was defined as the WebDAV namespace before standard best practices emerged, and this namespace is kept and still used because of significant existing deployments, but this should not be emulated. Well. The practice is not discouraged because registering new schemes is hard. It's the other way around: registering new schemes is hard because the IETF suggests using existing schemes whenever possible, and in this case, defining a new scheme was not necessary at all. Also, the *other* issue is using just a URI scheme name as a namespace name. This does not conform to RFC2396 (the character sequence "DAV:" is not a legal URI and thus should not have been used as namespace name). So I still think my proposed rewrite is more precise. 03-C05 4.5: “The value of a property appears inside the property name element. The value may be any text, including valid XML. When the value is structured as XML, namespaces that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later. Namespace prefixes need not be preserved due to the rules of prefix declaration in XML.” 1) I think this needs to rephrased to use proper XML terminology, also 2) I think that namespace prefixes within the property value do need to be roundtripped. Proposal: “The value of a property appears inside the property name element and may be any kind of well-formed XML content, including both text-only and mixed content. When the property value contains further XML elements, namespaces and namespace prefixes that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later.” Update draft -05/06: Issue 2 still needs to be resolved, the current text says: "Namespace prefixes need not be preserved due to the rules of prefix declaration in XML. This is incorrect because namespace prefixes *are* significant for certain XML vocabularies, such as XSLT and XML Schema. So independantly of what we decide for WebDAV, we should add an accurate statement about what that means for arbitrary XML content in properties. 03-C12: 8.1.1.: “Some of the following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources MUST use XML parsers that are compliant with [REC-XML].” Add “…and [REC-XMLNS]”. We also need allow servers and clients to rejects a certain set of request/response that are indeed well-formed, in particular: - when it exceeds some predefined size or - when expansion of internal entities may cause a denial of service. Update draft -05/06 the last issue still needs to be adressed 03-C14: 8.1.3: “When the Location header is used in a response, it is used by the server to indicate the preferred address for the target resource of the request. Whenever the server has a preferred address, it should use that address consistently. This means that when a response contains a Location header, all the URLs in the response body (e.g. a Multi-Status) should be consistent.” If we keep this paragraph, we’ll have to define what “consistent” means here. 03-C16: 8.1.5: “If ETags are supported for a resource, the server MUST return the ETag header in all PUT and GET responses to that resource, as well as provide the same value for the 'getetag' property.” Note that this breaks the “etag promotion” strategy used both by IIS and Moddav (PUT usually returns weak etags which later are promoted to strong etags when there was no other change to that resource within a specific time window). Therefore I’d make that a SHOULD (at least for PUT). 03-C17: 8.1.5.: “Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server MUST not change the ETag (or getlastmodified value) for a resource when only its property values change.” Some servers do, and I don't think we can change that. Therefore I think this change at least needs explicit consensus on the mailing list. As a minimum, I'd suggest changing MUST not (which should be "MUST NOT" anyway...) to "SHOULD NOT". Reason: there's a risk of making otherwise compliant servers non-compliant. All we gain in exchange is a possible (!) small improvement in ETag reliability. 03-C19: General comment re: 8.1.6: I really like that change (actually, I like it so much that I’d like to have condition names for all frequently signalled problems….). However, if it uses the same format as RFC3253, it should be consistent with it. In particular, the names should identify conditions that must be met. For instance, use “allow-external-entities” rather than “forbid-internal-entities”. We may also want to note that one DAV:error element can hold multiple elements identifying failed conditions. 03-C22: 8.2: “URLs for collections appearing in the results MUST end in a slash character.” I don’t think we have consensus for this being a MUST. 03-C24: 8.2.2: “This example also demonstrates the use of XML namespace scoping, and the default namespace. Since the "xmlns" attribute does not contain an explicit "shorthand name" (prefix) letter, the namespace applies by default to all enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace schema.” Change to: “This example also demonstrates the use of XML namespace scoping, and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all non-prefixed enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace.” (Actually I'd rather prefer to get rid of this. RFC2518bis shouldn't try to give XML lessons). Update re: -05: the spec still uses the term "namespace schema" which isn't a well-defined technical term. Just say "namespace". 03-C29: 9.1 (DAV header) allows coded URLs in the DAV header. I’d like to see the rationale for that. 03-C30: 9.4 (force-authenticate): is this the consensus we reached in January? Ilyas, did you take notes? 03-C31: 9.5 defines “” as a new special state token. I think this is unneeded – any URI which is known not to identify a lock MUST work as well, so we can simply recommend using something like “” (which is something that RFC2518-compliant servers already support). [This text changed, but it now makes "DAV:no-lock" a special feature of the grammar. This is not necessary. Just state that DAV:no-lock by definition never identifies a valid lock (because the WebDAV WG says so :-)] Update -05: the grammar was fixed, but the text still reads as if there's something special about DAV:no-lock. Just state that DAV:no-lock is an *example* for a URI that definitively will never identify a WebDAV lock, just like any other URI using the DAV: scheme. 03-C32: (old text) The example in 9.5.2 uses an invalid lock token (the URI scheme “locktoken” isn’t IETF-registered, so it can’t claim conformance to the uniqueness requirements). Just use a sample token using the “opaquelocktoken” scheme instead). [this now uses the right scheme, but an illegal token value] 03-C34: Section 13: XML element definitions I don’t like the syntax change in the DTDs. For instance, activelock now is defined as: ANY value: Any number of elements, including one of each of (lockscope, locktype, depth, owner, timeout, locktoken, lockroot) It used to be: For consistency with RFC2518, RFC3253 and the ACL spec we really should stay with the old notation. Update -05: the old notation is back, this is good. The spec now defines extensibility case-by-case, IMHO it should only define it when it's not the standard extensibilty. Also: "Extensibility: MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized." s/SHOULD/MUST/ 04-C01 attributes on properties Section 4.5: "Attributes on the property name element may convey information about the property, but are not considered part of the value." As far as I can tell, we haven't reached consensus on this. The latest discussion I'm aware of is at . 04-C02 lock discovery and tokens Section 6.3: "Finally, the lockdiscovery property can be queried using PROPFIND and the token can be discovered that way. Each lock has only one unique lock token." - the token can only be discovered this way if there aren't multiple tokens (due to shared locks) - clarify "has only one" by "has exactly one" 04-C05 sect 7.4, p2 "The lost-update problem is not an issue for collections because MKCOL can only be used to create a collection, not to overwrite an existing collection. In order to immediately lock a collection upon creation, clients may attempt to pipeline the MKCOL and LOCK requests together." There's no guarantee that this will be atomically, thus in the best case, it just makes a race condition less likely. As you can't rely on this to always succeed, I'd recommend not to say anything at all. 04-C06 sect 7.4, p3 "A lock request to an unmapped URL should result in the creation of a resource that is locked. A subsequent PUT request with the correct lock token should normally succeed, and provides the content, content-type, content-language and other information as appropriate." If this is supposed to be normative text, it should use "SHOULD" instead of "should" (same problem with many places where text was added). Besides, what is "should normally succeed" supposed to mean? Update -06: Still says "should normally succeed". Recommend leaving this out; it just behaves like any other empty resource. 04-C09, sect 8.1.3 ...speaks of "consistent" usage of addresses without precisely defining what that means. 04-C11, sect 8.1.5 p 2 This requirement will make both IIS and Apache/moddav non-compliant. Before I can agree to this, I'd like *at least* see the Apache/moddav developers committing to this change. 04-C13, sect 8.2 "Clients expect the fully-qualified URLs of members of a collection to have a common prefix which is the fully-qualified URL of the parent collection itself." If this is meant to define a normative requirement on server behaviour, it should be worded accordingly. "URLs in a PROPFIND response body MAY be represented as fully-qualified URLs, in which case they must all contain the full parent collection URL (scheme, host, port, and absolute path). Alternatively, these URLs MAY be absolute paths (not containing scheme, host or port), but in this case they must all still contain the full parent collection path." I'd strongly suggest to remove all of this and to clearly state using the RFC2396 productions what is allowed. 04-C17, sect 8.9, Copy for properties "If a property cannot be copied live, then its value MUST be duplicated, octet-for-octet, in an identically named, dead property on the destination resource." No! That would be a desaster. Make this "SHOULD NOT". Otherwise clients will see the dead property (such as DAV:checked-in) and make wrong assumptions about the resource. Update -06: this text still is in, now in 8.9.2. 04-C20, sect 8.10.1 "Live properties described in this document MUST be moved along with the resource, such that the resource has identically behaving live properties at the destination resource, but not necessarily with the same values. If the live properties will not work the same way at the destination, the server MUST fail the request (the client can perform COPY then DELETE if it wants a MOVE to work that badly). This can mean that the server removes a live property if that's the most appropriate behavior for that live property at the destination." The second sentence implies that the MOVE must fail if the live properties can't be moved as well, while the last sentence says that the server may remove the live properties. Update -05: this now reads: This can mean that the server reports the live property as "Not Found" if that's the most appropriate behavior for that live property at the destination, as long as the live property is still supported with the same semantics. I'm not sure I understand what that means. The contradiction is still there. "A MOVE can be a rename operation, so it's not appropriate to reset live properties which are set at resource creation. For example, the creationdate property value SHOULD remain the same." So can a MOVE be something else then a rename operation? If yes, how does the second sentence then applies? If it doesn't apply always, and the client won't know, why are we mentioning it? Update -06: this has been reworded again, but I still think it's misleading. MOVE may or may not create a new resource (as RFC2518 explicitly allows COPY/DELETE semantics). When it does, the creationdate will change. When it doesn't, it won't. 04-C21, sect 8.11, refreshing LOCKs "A lock is refreshed by sending a new LOCK request to the resource which is the root of the lock. A LOCK request to refresh a lock must specify which lock to refresh by using the Lock-Token header with a single lock token (only one lock may be refreshed at a time). This request does not contain a body, but it may contain a Timeout header. A server MAY accept the Timeout header to change the duration remaining on the lock to the new value." Replace by "A lock is refreshed by applying a LOCK request to the URL which is the root of the lock. This request must specify which lock to refresh by using the Lock-Token header with a single lock token (only one lock may be refreshed at a time) and does not contain a body, but it may contain a Timeout header. A server MAY accept the Timeout header to change the duration remaining on the lock to the new value." Update -06: now in 8.11.1. Please update the first sentence as proposed. 04-C22, sect 8.11.1 Fix the XML response by replacing http://example.com/workspace/webdav /proposal.doc by something like http://example.com/workspace/webdav/proposal.doc< /D:href> Update -06: now in 8.11.7. 04-C24, section 11 I think this section doesn't really help. It doesn't seem to say anything normative, so I'd recommend to drop it, and to improve the sections for the individual methods. 04-C28, section 14, displayname "It MAY be attempted to be set in remote COPY operation." I'd say: it MUST NOT. "This property is live and MAY be protected." What's the use case for it being protected? Update -06: now in section 14.2. 04-C29, section 14 Uses the term "remote COPY operation" and "cross-server copy". I think we need to define what this means. 04-C30, section 14.5 "In a remote COPY operation that is implemented through a GET request, the GET request must have the appropriate Content-Type header." I honestly don't understand what this means. Update -05: now it says PUT instead of GET. Aha! Anyway, I don't think this belongs into a description of a live property. 04-C32, section 17 "It is only in the case where the set of properties is not known ahead of time that an application need display a property name URI to a user" There is no such thing as a "property name URI", unless we define it. (note the term occurs twice, only one instance was changed; also, just use "property name" -- this includes both local name and namespace). Update -06: now in section 18. Editorial notes: 04-E02 usage of sample host names not according to IETF recommendations 04-E04 Numbering of appendices Each appendix should have it's own section number. draft-rfc-editor-rfc2223bis-06.txt seems to recommand uppercase letters (such as "Appendix A"). 04-E05 wrong reference Page 7, 2nd paragraph refers to 13.28, I think this needs to be 14. Update -05: the sentence with the reference was removed. Why not keep it and just fix the reference? 04-E06 Terminology URI/URL: note we should be prepared to update to RFC2396bis when it's ready. 04-E07 usage of property names in surrounding text I think we should try to use a consistent syntax when referring to DAV: properties. Currently we have a mix between "foo" and "DAV:foo". 04-E08 section 3: definition of "null resource" ...is gone, yet is still used in later sections. 04-E09 "DAV compliant" I think we should try to use either "DAV compliant" or "WebDAV compliant" consistently. 04-E13 paragraph numbering in sec 13 ...is broken. For instance, 13.2 should be a subsection of 13.1 [1] [2] [3] [4] [5] [6] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Sep 11 13:57: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 NAA29932 for ; Sat, 11 Sep 2004 13:57:25 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6C7C-00027l-DM; Sat, 11 Sep 2004 17:56:46 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C6C7B-00027F-Nz for w3c-dist-auth@listhub.w3.org; Sat, 11 Sep 2004 17:56:45 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1C6C7B-0002XF-25 for w3c-dist-auth@w3.org; Sat, 11 Sep 2004 17:56:45 +0000 Received: (qmail 15960 invoked by uid 65534); 11 Sep 2004 17:56:11 -0000 Received: from pD9535A45.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.90.69) by mail.gmx.net (mp021) with SMTP; 11 Sep 2004 19:56:11 +0200 X-Authenticated: #1915285 Message-ID: <41433C2B.7020702@gmx.de> Date: Sat, 11 Sep 2004 19:55:55 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; 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: Issues with rfc2518bis-06 (part 2) X-Archived-At: http://www.w3.org/mid/41433C2B.7020702@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8817 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, 11 Sep 2004 17:56:46 +0000 Content-Transfer-Encoding: 7bit Hi, this is a summary of issues either new in draft -05 or issues with changes between drafts 04 and 05. It was first submitted in October 2003 ([1]), but as far as I can tell, non of the issues was adressed. 05-C01 media types Looking at the current W3 TAG discussion about XML media types we may want to consider deprecating "text/xml" and making "application/xml" a SHOULD. 05-C02 "illformed" Section 8.1.1 s/ill-formed/non-wellformed/ 05-C03 OPTIONS * 9.1 contains the new paragraph: This header must also appear on responses to OPTIONS requests to the special '*' Request-URI as defined in HTTP/1.1. In this case it means that the repository supports the named features in at least some internal namespaces. 1) I don't remember this being discussed anywhere. 2) This is impossible to implement with the Java Servlet API, so it's unlikely to be implemented 3) This clearly contradicts RFC2616, sectopn 9.2 (): "If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof)." 05-C04 DAV request header Thanks for adding it, however I think we need to do some more work: As an optional request header, this header allows the client to advertise compliance with named features. Clients need not advertise 1, 2 or bis because a WebDAV server currently doesn't need that information to decide how to respond to requests defined in this specification or in HTTP/1.1. However, future extensions may define client compliance codes. When used as a request header, the DAV header MAY affect caching so this header SHOULD NOT be used on all GET requests. 1) Just say generally that only those feature names are allowed where the spec explicitly defines what it means (in a request!). For RFC2518bis this means that none of the feature names defined here may be used. 2) "When used as a request header, the DAV header MAY affect caching so this header SHOULD NOT be used on all GET requests." - this is misleading. Either it is allowed on GET, or it isn't. If the request header affects a cacheable GET result, the origin server MUST specify that in the "Vary" header. 05-C05 Multistatus format Section 12: When a Multi-Status body is returned in response to a PROPFIND or another request with a single scope, all URLs appearing in the body must be equal to or inside the request-URI, thus the URLs MAY be absolute or MAY be relative. What is a "single" scope. Ans what does it mean for a URI to be "inside" another? It continues saying: When a Multi-Status body is returned in response to MOVE or COPY, relative URIs resolution is ambiguous (the request had both a source and a destination URL). Thus, URLs appearing in the responses to MOVE or COPY SHOULD be absolute and fully-qualified URLs. What is a "fully-qualified" URL? If this is meant to say that the URI, when relative, MUST start with a "/", then it should be more clear about that. 05-C06 12.1 3xx handling The 300-303, 305 and 307 responses defined in HTTP 1.1 normally take a Location header to indicate where the client should make the request. The Multi-Status response syntax as defined in RFC2518 did not allow for the Location header information to be included in an unambiguous way, so servers MAY choose not to use these status codes in Multi-Status responses. If a clients receives this status code in Multi-Status, the client MAY reissue the request to the individual resource, so that the server can issue a response with a Location header for each resource. Additionally, this specification defines a new element that servers MAY use in the response element to provide a location value in Multi-Status (see section 13.29). I think we can improve that: - "not to use" -- be clear what this means -- is it using a "200" status element instead? - when the server chooses not to return the 3xx code, should it include the location element nevertheless (I think it should) 05-C07 XML Extensibility (section 13) I still think we should make statements about extensibility once. The current notation (adding verbose text to each and every element description) just makes the spec less readable and harder to maintain. Note that already the descriptions are partly broken (for instance in 13.18). In particular: Extensibility: MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized. s/SHOULD/MUST/ 05-C08 propfind DTD Says: Should be: 05-C09 Properties Some property values are calculated by the server and it is not appropriate to allow client changes, thus they are protected. Existing server implementations already have different sets of RFC2518 properties protected, but clients can have some expectations which properties are normally protected. The value of a protected property may not be changed even by a user with permission to edit other properties. The value of an unprotected property may be changed by some users with appropriate permissions. This definition seems to slightly differ from what RFC3253 says. That seems to be a bad idea (here is seems to identify "calculated" with "protected"; in RFC3253 there's a clear difference between "protected" and "computed"). 05-C10 Properties (COPY/MOVE behaviour) This somehow combines statements about how the property behaves upon COPY and MOVE (good) and some statements about what happens in "remote" operations. I think the latter is very confusing. Either a copy is done using COPY, or it isn't. If a server decides to emulate a copy operation using PROPPATCH and PUT, the standard considerations for these methods apply. 05-C11 "mandatory" properties This is actually an old issue. For instance: Description: The creationdate property should be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created (i.e., the moment it had non-null state). Basically this says that the property should be there, unless it isn't. Just say that it's optional in these cases. [1] From w3c-dist-auth-request@w3.org Sat Sep 11 14:03: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 OAA00315 for ; Sat, 11 Sep 2004 14:03:58 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6CDg-000407-KR; Sat, 11 Sep 2004 18:03:28 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C6CDg-0003zQ-60 for w3c-dist-auth@listhub.w3.org; Sat, 11 Sep 2004 18:03:28 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C6CDf-0003Po-Im for w3c-dist-auth@w3.org; Sat, 11 Sep 2004 18:03:27 +0000 Received: (qmail 792 invoked by uid 65534); 11 Sep 2004 18:02:56 -0000 Received: from pD9535A45.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.90.69) by mail.gmx.net (mp002) with SMTP; 11 Sep 2004 20:02:56 +0200 X-Authenticated: #1915285 Message-ID: <41433DBA.7070608@gmx.de> Date: Sat, 11 Sep 2004 20:02:34 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <41433C2B.7020702@gmx.de> In-Reply-To: <41433C2B.7020702@gmx.de> Content-Type: text/plain; charset=us-ascii; 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: Issues with rfc2518bis-06 (part 2) X-Archived-At: http://www.w3.org/mid/41433DBA.7070608@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8818 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, 11 Sep 2004 18:03:28 +0000 Content-Transfer-Encoding: 7bit Forgot this one...: 05-C13 extensibility of responsedescription element Section 13.19 states: "Extensibility: MAY be extended with attributes which SHOULD be ignored." However: RFC3253, section 1.6 *already* does extend it with a child element (DAV:error). (added for -06) Bottom line: RFC2518bis should properly copy RFC3253's definition of precondition/postcondition, DAV:error element and it's usage in DAV:multistatus. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Sep 11 15:29: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 PAA05600 for ; Sat, 11 Sep 2004 15:29:16 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6DYB-0008OL-Ib; Sat, 11 Sep 2004 19:28:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C6DYA-0008ML-Sr for w3c-dist-auth@listhub.w3.org; Sat, 11 Sep 2004 19:28:42 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1C6DY9-0005yr-AF for w3c-dist-auth@w3.org; Sat, 11 Sep 2004 19:28:41 +0000 Received: (qmail 29462 invoked by uid 65534); 11 Sep 2004 19:28:09 -0000 Received: from pD9535A45.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.90.69) by mail.gmx.net (mp018) with SMTP; 11 Sep 2004 21:28:09 +0200 X-Authenticated: #1915285 Message-ID: <414351A2.2080505@gmx.de> Date: Sat, 11 Sep 2004 21:27:30 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; 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: Issues with rfc2518bis-06 (part 3) X-Archived-At: http://www.w3.org/mid/414351A2.2080505@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8819 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, 11 Sep 2004 19:28:43 +0000 Content-Transfer-Encoding: 7bit This is a summary of issues either new in draft -05 or issues with changes between drafts 05 and 06. 06-C01 Locks vs mutltiple URLs I appreciate the clarification on locking. Currently it says: 6.8 Locks and Multiple Bindings 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. This is a bit misleading as indeed the lock is on the resource, but it *protects* the URL through which the lock was created. Thus given URLs "a" and "b" identifying the same resource which was locked through "a", I can apply DELETE to "b" without needing the lock token. This seems to be another example why it would be A Good Thing to completely import GULP (see for instance ) into the spec. 06-C02 Section 7.5 "and the response SHOULD contain the 'missing-lock-token' precondition." Spec should copy precondition/postcondition terminology from RFC3253; while doing this, please change to identifiers that actually *name* the condition, such as DAV:need-lock-token in . (same applies to almost all condition names defined by the document). 06-C03 Section 8.2 Multistatus Format The multistatus contains one response element for each resource in the scope of the request (in no required order) or may be empty if no resources match the request. Although this is correct, I find it confusing that it's stated for PROPFIND where this condition never occur. It should be mentioned in the definition of the multistatus element instead. 06-C04 Section 8.3.1 Multistatus status codes Why would we ever return a 423 in a 207 response body to a *PROPPATCH*? 06-C04 Section 8.9.3 ..refers to 8.7.2 for "namespace consistency". That's in 5.1, though. 06-C05 Section 8.10.4 Speaking of MOVE...: 403 (Forbidden) - The source and destination resources are the same. This is a very good example for why we need to go through *all* response code examples in the document. A 403 upon MOVE can mean a lot of things, and the only way to distinguish these is by using proper condition codes. 06-C06, 8.11.6 423 (Locked) - The resource is locked already. For consistency's sake, this response SHOULD contain the 'missing-lock-token' precondition element. I find this misleading. We have a strict separation between LOCK creation (with request body) and LOCK refresh (without). If a LOCK creation request fails because the resource is already exclusively locked, providing the lock token in the If header will not help at all. 06-C07, 8.12 The If header is not needed to provide the lock token although servers SHOULD still evaluate the If header and treat it as a conditional header. I agree with that, but I'm confused it's mentioned here. Doesn't it apply to *all* HTTP methods? 06-C08, 9.5.4, lock token syntax Uses an invalid lock token () 06-C09, 13.7 href element Purpose: Identifies the content of the element as a URI. In many situations, this URI MUST be a HTTP URI, and furthermore, it MUST identify a WebDAV resource. There is one exception to this general rule in the lockdiscovery property, where the lock token (which is a URI but may not be a HTTP URI) is inside the href element. Other specifications SHOULD be explicit if the href element is to contain non-HTTP URIs. Wow? Since when? May it refer to a null resource? Is a null resource a WebDAV resource? What about location/href, for instance? Unless there's consensus for this incompatible change to RFC2518, please remove it. Value: URI (See section 3.2.1 of RFC2616 [8]) No. URIs are defined in RFC2396(bis). 06-C10, 13.16 Typo in "Name:" line. 06-E01 Boilerplate The front page should refer to RFC3667, not RFC2026. In xml2rfc source code, do this using ipr="full3667" on the root element. 06-E02 TOC gone The TOC is gone. Please bring it back. 06-E03 Reference style References now use numerical names instead of symbolic ones. Is there a reason for this change? (use in xml2rfc source code) 06-E04 non-ASCII characters In section 7.6, 8.1.6, 8.2, 8.7.2 and probably some more places. 06-E05 XML references Please update XML reference to "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC-xml-20040204, February 2004. 06-E06 Appendix B.2 Formatting of list was lost. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Sep 12 08:20: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 IAA11900 for ; Sun, 12 Sep 2004 08:20:42 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6TKk-0005Hw-Nz; Sun, 12 Sep 2004 12:19:54 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C6TKj-0005G3-Uw for w3c-dist-auth@listhub.w3.org; Sun, 12 Sep 2004 12:19:53 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1C6TKj-000372-Bk for w3c-dist-auth@w3.org; Sun, 12 Sep 2004 12:19:53 +0000 Received: (qmail 18753 invoked by uid 65534); 12 Sep 2004 12:19:21 -0000 Received: from pD9535A45.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.90.69) by mail.gmx.net (mp024) with SMTP; 12 Sep 2004 14:19:21 +0200 X-Authenticated: #1915285 Message-ID: <41443EC2.9060808@gmx.de> Date: Sun, 12 Sep 2004 14:19:14 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: www-webdav-dasl@w3.org References: <41357711.1080309@gmx.de> In-Reply-To: <41357711.1080309@gmx.de> Content-Type: text/plain; charset=us-ascii; 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: Last-calling draft-reschke-webdav-property-datatypes-07, Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/41443EC2.9060808@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8820 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: Sun, 12 Sep 2004 12:19:54 +0000 Content-Transfer-Encoding: 7bit Hi, so far I haven't received any feedback on the content of the latest property datatypes draft (announcement in [1], TXT and HTML versions at [2] and [3]). I'm therefore last-calling this draft, with the goal of submitting a minimally revised version (see below) for publication as "Experimental RFC" in two weeks from now. Quoting from "The Internet Standards Process -- Revision 3" (), section 4.2.1: 4.2.1 Experimental The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an individual contribution. I think that this protocol extension falls under this definition; the WebDAV working group currently doesn't seem to plan working on it itself, but the protocol is already implemented by different vendors, and thus it's a good thing to have it documented and published. Furthermore, it hasn't changed significantly since it was proposed first in August 2001. Also, the IETF is the right place to do this as it extends another IETF protocol (RFC2518). If the working group at a later point decides to work on property datatypes itself, it can use the document as a basis (with real world deployment), or it can still decide to define something completely different. Edits continue on the "latest" version ([4]). Right now I'm only planning to simplify the subsection nesting (which really is only an artefact from the time when the draft also spoke about two other features, property flags and displayname information). Best regards, Julian [1] [2] [3] [4] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Sep 12 13:41: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 NAA29693 for ; Sun, 12 Sep 2004 13:41:06 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6YL0-0001Pl-69; Sun, 12 Sep 2004 17:40:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C6YKz-0001Ok-FY for w3c-dist-auth@listhub.w3.org; Sun, 12 Sep 2004 17:40:29 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1C6YKx-000826-RB for w3c-dist-auth@w3c.org; Sun, 12 Sep 2004 17:40:28 +0000 Received: (qmail 25724 invoked by uid 65534); 12 Sep 2004 17:39:55 -0000 Received: from pD9FF0275.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.2.117) by mail.gmx.net (mp003) with SMTP; 12 Sep 2004 19:39:55 +0200 X-Authenticated: #1915285 Message-ID: <414489DF.60904@gmx.de> Date: Sun, 12 Sep 2004 19:39:43 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Webdav WG'" Content-Type: multipart/mixed; boundary="------------080703020605050803080105" 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: LOCK refresh on indirectly locked resource X-Archived-At: http://www.w3.org/mid/414489DF.60904@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8821 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: Sun, 12 Sep 2004 17:40:30 +0000 This is a multi-part message in MIME format. --------------080703020605050803080105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It's some time ago that somebody asked how servers implement this today. I finally got around to write a test case (attached JScript), including 1) using a no-tag list If header, 2) using a tagged If header, specifying the lock root and 2) using a tagged If header, specifying the indirectly locked resource. Results: IIS5: does not support depth infinity locks on collections SAP EP 5.x: allows all combinations Xythos Webfile Server (current version from www.sharemation.com): allows all combinations, but seems to loose the timeout upon lock refresh Apache2.0.50/mod_dav: *crashes*, see So I'd propose to wait what the Apache/mod_dav developers have to say. Right now it seems that servers do not seem to care. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 --------------080703020605050803080105 Content-Type: application/x-javascript; name="indirect-lock-refresh.js" Content-Disposition: inline; filename="indirect-lock-refresh.js" Content-Transfer-Encoding: 7bit var req = new ActiveXObject ("MSXML2.ServerXMLHTTP"); var uri = WScript.Arguments(0); var user = null; var pwd = null; if (WScript.Arguments.length > 1) { user = WScript.Arguments(1); } if (WScript.Arguments.length > 2) { pwd = WScript.Arguments(2); } function dumpResponse(r) { WScript.Echo(r.status); WScript.Echo(r.getAllResponseHeaders()); WScript.Echo(r.responseText); } // delete target just in case WScript.Echo("DELETE " + uri); req.open("DELETE", uri, false, user, pwd); req.send(); dumpResponse(req); // create collection WScript.Echo("MKCOL " + uri); req.open("MKCOL", uri, false, user, pwd); req.send(); if ((req.status < 200 || req.status >= 300) && req.status != 405) { WScript.Echo("unexpected status upon MKCOL:" + req.status + " " + req.responseText); WScript.Quit(2); } dumpResponse(req); // put content WScript.Echo("PUT " + uri + "/a"); req.open("PUT", uri + "/a", false, user, pwd); req.send("foobar"); if (req.status < 200 || req.status >= 300) { WScript.Echo("unexpected status upon PUT: " + req.status + " " + req.responseText); WScript.Quit(2); } dumpResponse(req); WScript.Echo("LOCK " + uri); req.open("LOCK", uri, false, user, pwd); req.setRequestHeader("Depth", "infinity"); req.setRequestHeader("Timeout", "Second-60"); req.send(""); dumpResponse(req); var locktoken = null; try { locktoken = req.getResponseHeader("lock-token"); } catch (x) {} if (locktoken == null || locktoken == "") { WScript.Echo("server did not return lock token, trying response body"); WScript.Echo(req.responseText); req.responseXML.setProperty("SelectionLanguage", "XPath"); locktoken = req.responseXML.selectSingleNode("//*[local-name()='href']").text; } else { locktoken = locktoken.substring(1, locktoken.length - 1); } if (req.status == 200 || req.status == 201) { WScript.Echo("locktoken: " + locktoken); } else { WScript.Echo("resource not locked, status: " + req.status + " " + req.responseText); WScript.Quit(2); } // attempt LOCK refresh on indirectly locked resource /a with tag list on parent WScript.Echo("LOCK refresh " + uri + "/a tagged-list on /"); req.open("LOCK", uri + "/a", false, user, pwd); req.setRequestHeader("If", "<" + uri + "> (<" + locktoken + ">)"); req.send(); dumpResponse(req); // attempt LOCK refresh on indirectly locked resource /a WScript.Echo("LOCK refresh " + uri + "/a no-tag list"); req.open("LOCK", uri + "/a", false, user, pwd); req.setRequestHeader("If", "(<" + locktoken + ">)"); req.send(); dumpResponse(req); // attempt LOCK refresh on indirectly locked resource /a WScript.Echo("LOCK refresh " + uri + "/a tagged-list on /a"); req.open("LOCK", uri + "/a", false, user, pwd); req.setRequestHeader("If", "<" + uri + "/a> (<" + locktoken + ">)"); req.send(); dumpResponse(req); --------------080703020605050803080105-- From w3c-dist-auth-request@w3.org Sun Sep 12 14:23: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 OAA02465 for ; Sun, 12 Sep 2004 14:23:07 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6Yzj-0000OI-8I; Sun, 12 Sep 2004 18:22:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C6Yzi-0000Nh-R3 for w3c-dist-auth@listhub.w3.org; Sun, 12 Sep 2004 18:22:34 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.101]) by lisa.w3.org with esmtp (Exim 4.34) id 1C6Yzh-0005Q1-9P for w3c-dist-auth@w3.org; Sun, 12 Sep 2004 18:22:33 +0000 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i8CIM3E1384736 for ; Sun, 12 Sep 2004 14:22:03 -0400 Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8CINFhv170160 for ; Sun, 12 Sep 2004 14:23:16 -0400 In-Reply-To: <414351A2.2080505@gmx.de> 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: Sun, 12 Sep 2004 14:22:01 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF535 | September 3, 2004) at 09/12/2004 14:22:02, Serialize complete at 09/12/2004 14:22:02 Content-Type: multipart/alternative; boundary="=_alternative 0064E52D85256F0D_=" 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: Issues with rfc2518bis-06 (part 1-3) X-Archived-At: http://www.w3.org/mid/OF8546F807.420FA08B-ON85256F0D.00641E47-85256F0D.0064E52E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8822 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: Sun, 12 Sep 2004 18:22:35 +0000 This is a multipart message in MIME format. --=_alternative 0064E52D85256F0D_= Content-Type: text/plain; charset="US-ASCII" I agree with the suggested fixes made by Julian in these issue lists. And I'd especially like to thank Julian for his comprehensive reviews, and his careful tracking of the state of these issues. Cheers, Geoff Julian wrote on 09/11/2004 03:27:30 PM: > This is a summary of issues either new in draft -05 or issues with > changes between drafts 05 and 06. > > > 06-C01 Locks vs mutltiple URLs > > I appreciate the clarification on locking. Currently it says: > > 6.8 Locks and Multiple Bindings > > 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. > > This is a bit misleading as indeed the lock is on the resource, but it > *protects* the URL through which the lock was created. Thus given URLs > "a" and "b" identifying the same resource which was locked through "a", > I can apply DELETE to "b" without needing the lock token. > > This seems to be another example why it would be A Good Thing to > completely import GULP (see for instance > latest.html#gulp>) > into the spec. > > > 06-C02 Section 7.5 > > "and the response SHOULD contain the 'missing-lock-token' precondition." > > Spec should copy precondition/postcondition terminology from RFC3253; > while doing this, please change to identifiers that actually *name* the > condition, such as DAV:need-lock-token in > latest.html#rfc.section.8.2.2>. > (same applies to almost all condition names defined by the document). > > > 06-C03 Section 8.2 Multistatus Format > > The multistatus contains one response element for each > resource in the scope of the request (in no required order) or may be > empty if no resources match the request. > > Although this is correct, I find it confusing that it's stated for > PROPFIND where this condition never occur. It should be mentioned in the > definition of the multistatus element instead. > > > 06-C04 Section 8.3.1 Multistatus status codes > > Why would we ever return a 423 in a 207 response body to a *PROPPATCH*? > > > 06-C04 Section 8.9.3 > > ..refers to 8.7.2 for "namespace consistency". That's in 5.1, though. > > > 06-C05 Section 8.10.4 > > Speaking of MOVE...: > > 403 (Forbidden) - The source and destination resources are the same. > > This is a very good example for why we need to go through *all* response > code examples in the document. A 403 upon MOVE can mean a lot of things, > and the only way to distinguish these is by using proper condition codes. > > > 06-C06, 8.11.6 > > 423 (Locked) - The resource is locked already. For consistency's > sake, this response SHOULD contain the 'missing-lock-token' > precondition element. > > I find this misleading. We have a strict separation between LOCK > creation (with request body) and LOCK refresh (without). If a LOCK > creation request fails because the resource is already exclusively > locked, providing the lock token in the If header will not help at all. > > > 06-C07, 8.12 > > The If header is not needed > to provide the lock token although servers SHOULD still evaluate the > If header and treat it as a conditional header. > > I agree with that, but I'm confused it's mentioned here. Doesn't it > apply to *all* HTTP methods? > > > 06-C08, 9.5.4, lock token syntax > > Uses an invalid lock token () > > > 06-C09, 13.7 href element > > Purpose: Identifies the content of the element as a URI. In many > situations, this URI MUST be a HTTP URI, and furthermore, it MUST > identify a WebDAV resource. There is one exception to this > general rule in the lockdiscovery property, where the lock token > (which is a URI but may not be a HTTP URI) is inside the href > element. Other specifications SHOULD be explicit if the href > element is to contain non-HTTP URIs. > > Wow? Since when? May it refer to a null resource? Is a null resource a > WebDAV resource? What about location/href, for instance? Unless there's > consensus for this incompatible change to RFC2518, please remove it. > > Value: URI (See section 3.2.1 of RFC2616 [8]) > > No. URIs are defined in RFC2396(bis). > > > 06-C10, 13.16 > > Typo in "Name:" line. > > > > > > 06-E01 Boilerplate > > The front page should refer to RFC3667, not RFC2026. In xml2rfc source > code, do this using ipr="full3667" on the root element. > > > 06-E02 TOC gone > > The TOC is gone. Please bring it back. > > > 06-E03 Reference style > > References now use numerical names instead of symbolic ones. Is there a > reason for this change? (use in xml2rfc source code) > > > 06-E04 non-ASCII characters > > In section 7.6, 8.1.6, 8.2, 8.7.2 and probably some more places. > > > 06-E05 XML references > > Please update XML reference to "Extensible Markup Language (XML) 1.0 > (Third Edition)", W3C REC-xml-20040204, February 2004. > > > 06-E06 Appendix B.2 > > Formatting of list was lost. > > > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > --=_alternative 0064E52D85256F0D_= Content-Type: text/html; charset="US-ASCII"
I agree with the suggested fixes made by Julian in these issue lists.
And I'd especially like to thank Julian for his comprehensive reviews,
and his careful tracking of the state of these issues.

Cheers,
Geoff


Julian wrote on 09/11/2004 03:27:30 PM:
> This is a summary of issues either new in draft -05 or issues with
> changes between drafts 05 and 06.
>
>
> 06-C01 Locks vs mutltiple URLs
>
> I appreciate the clarification on locking. Currently it says:
>
>     6.8  Locks and Multiple Bindings
>
>     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.
>
> This is a bit misleading as indeed the lock is on the resource, but it
> *protects* the URL through which the lock was created. Thus given URLs
> "a" and "b" identifying the same resource which was locked through "a",
> I can apply DELETE to "b" without needing the lock token.
>
> This seems to be another example why it would be A Good Thing to
> completely import GULP (see for instance
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-
> latest.html#gulp>)
> into the spec.
>
>
> 06-C02 Section 7.5
>
> "and the response SHOULD contain the 'missing-lock-token' precondition."
>
> Spec should copy precondition/postcondition terminology from RFC3253;
> while doing this, please change to identifiers that actually *name* the
> condition, such as DAV:need-lock-token in
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-
> latest.html#rfc.section.8.2.2>.
> (same applies to almost all condition names defined by the document).
>
>
> 06-C03 Section 8.2 Multistatus Format
>
>     The multistatus contains one response element for each
>     resource in the scope of the request (in no required order) or may be
>     empty if no resources match the request.
>
> Although this is correct, I find it confusing that it's stated for
> PROPFIND where this condition never occur. It should be mentioned in the
> definition of the multistatus element instead.
>
>
> 06-C04 Section 8.3.1 Multistatus status codes
>
> Why would we ever return a 423 in a 207 response body to a *PROPPATCH*?
>
>
> 06-C04 Section 8.9.3
>
> ..refers to 8.7.2 for "namespace consistency". That's in 5.1, though.
>
>
> 06-C05 Section 8.10.4
>
> Speaking of MOVE...:
>
>     403 (Forbidden) - The source and destination resources are the same.
>
> This is a very good example for why we need to go through *all* response
> code examples in the document. A 403 upon MOVE can mean a lot of things,
> and the only way to distinguish these is by using proper condition codes.
>
>
> 06-C06, 8.11.6
>
>     423 (Locked) - The resource is locked already.  For consistency's
>     sake, this response SHOULD contain the 'missing-lock-token'
>     precondition element.
>
> I find this misleading. We have a strict separation between LOCK
> creation (with request body) and LOCK refresh (without). If a LOCK
> creation request fails because the resource is already exclusively
> locked, providing the lock token in the If header will not help at all.
>
>
> 06-C07, 8.12
>
>     The If header is not needed
>     to provide the lock token although servers SHOULD still evaluate the
>     If header and treat it as a conditional header.
>
> I agree with that, but I'm confused it's mentioned here. Doesn't it
> apply to *all* HTTP methods?
>
>
> 06-C08, 9.5.4, lock token syntax
>
> Uses an invalid lock token (<locktoken:a-write-lock-token>)
>
>
> 06-C09, 13.7 href element
>
>     Purpose:  Identifies the content of the element as a URI.  In many
>        situations, this URI MUST be a HTTP URI, and furthermore, it MUST
>        identify a WebDAV resource.  There is one exception to this
>        general rule in the lockdiscovery property, where the lock token
>        (which is a URI but may not be a HTTP URI) is inside the href
>        element.  Other specifications SHOULD be explicit if the href
>        element is to contain non-HTTP URIs.
>
> Wow? Since when? May it refer to a null resource? Is a null resource a
> WebDAV resource? What about location/href, for instance? Unless there's
> consensus for this incompatible change to RFC2518, please remove it.
>
>     Value:  URI (See section 3.2.1 of RFC2616 [8])
>
> No. URIs are defined in RFC2396(bis).
>
>
> 06-C10, 13.16
>
> Typo in "Name:" line.
>
>
>
>
>
> 06-E01 Boilerplate
>
> The front page should refer to RFC3667, not RFC2026. In xml2rfc source
> code, do this using ipr="full3667" on the root element.
>
>
> 06-E02 TOC gone
>
> The TOC is gone. Please bring it back.
>
>
> 06-E03 Reference style
>
> References now use numerical names instead of symbolic ones. Is there a
> reason for this change? (use <?rfc symrefs="yes"?> in xml2rfc source code)
>
>
> 06-E04 non-ASCII characters
>
> In section 7.6, 8.1.6, 8.2, 8.7.2 and probably some more places.
>
>
> 06-E05 XML references
>
> Please update XML reference to "Extensible Markup Language (XML) 1.0
> (Third Edition)", W3C REC-xml-20040204, February 2004.
>
>
> 06-E06 Appendix B.2
>
> Formatting of list was lost.
>
>
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>
--=_alternative 0064E52D85256F0D_=-- From w3c-dist-auth-request@w3.org Mon Sep 13 04:58: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 EAA07491 for ; Mon, 13 Sep 2004 04:58:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6mey-0000te-5s; Mon, 13 Sep 2004 08:58:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C6mex-0000rP-2M for w3c-dist-auth@listhub.w3.org; Mon, 13 Sep 2004 08:58:03 +0000 Received: from mta06-svc.ntlworld.com ([62.253.162.46]) by lisa.w3.org with esmtp (Exim 4.34) id 1C6mev-0006fP-Cn for w3c-dist-auth@w3c.org; Mon, 13 Sep 2004 08:58:01 +0000 Received: from manyfish.co.uk ([81.105.239.46]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040913085745.BEVR2251.mta06-svc.ntlworld.com@manyfish.co.uk> for ; Mon, 13 Sep 2004 09:57:45 +0100 Received: from monolith.fishnet (localhost.localdomain [127.0.0.1]) by manyfish.co.uk (8.12.11/8.12.5) with ESMTP id i8D8vTjH029076 for ; Mon, 13 Sep 2004 09:57:29 +0100 Received: (from joe@localhost) by monolith.fishnet (8.12.11/8.12.11/Submit) id i8D8vT3X029075 for w3c-dist-auth@w3c.org; Mon, 13 Sep 2004 09:57:29 +0100 Date: Mon, 13 Sep 2004 09:57:29 +0100 From: Joe Orton To: "'Webdav WG'" Message-ID: <20040913085729.GA28982@manyfish.co.uk> Mail-Followup-To: 'Webdav WG' References: <414489DF.60904@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <414489DF.60904@gmx.de> User-Agent: Mutt/1.4.1i Received-SPF: none (lisa.w3.org: domain of joe@manyfish.co.uk does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: LOCK refresh on indirectly locked resource X-Archived-At: http://www.w3.org/mid/20040913085729.GA28982@manyfish.co.uk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8823 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 Sep 2004 08:58:04 +0000 On Sun, Sep 12, 2004 at 07:39:43PM +0200, Julian Reschke wrote: > It's some time ago that somebody asked how servers implement this today. > I finally got around to write a test case (attached JScript), including > > 1) using a no-tag list If header, > 2) using a tagged If header, specifying the lock root and > 2) using a tagged If header, specifying the indirectly locked resource. Is your latter (2) behaviour defined by 2518 or 2518bis? I suppose both are equivalent by 2518 at least. > Results: ... > Apache2.0.50/mod_dav: *crashes*, see > It looks like the code path for indirectly refreshing the lock had never been tested in mod_dav, it has never worked AFAICT. I can't find any reports of this bug being triggered before, either, so I guess this is not the most widely used protocol feature... (I've made a new release of the litmus test suite which also includes a test for an indirect lock refresh for any others who are interested and can't run JScript: http://www.webdav.org/neon/litmus/) Regards, joe From w3c-dist-auth-request@w3.org Mon Sep 13 06:22: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 GAA13012 for ; Mon, 13 Sep 2004 06:22:12 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6nxr-000196-Gm; Mon, 13 Sep 2004 10:21:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C6nxq-00018V-Ow for w3c-dist-auth@listhub.w3.org; Mon, 13 Sep 2004 10:21:38 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1C6nxp-0004Ox-2g for w3c-dist-auth@w3c.org; Mon, 13 Sep 2004 10:21:37 +0000 Received: (qmail 5800 invoked by uid 65534); 13 Sep 2004 09:21:06 -0000 Received: from p50825031.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.80.49) by mail.gmx.net (mp027) with SMTP; 13 Sep 2004 11:21:06 +0200 X-Authenticated: #1915285 Message-ID: <41456680.4020108@gmx.de> Date: Mon, 13 Sep 2004 11:21:04 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Orton CC: "'Webdav WG'" References: <414489DF.60904@gmx.de> <20040913085729.GA28982@manyfish.co.uk> In-Reply-To: <20040913085729.GA28982@manyfish.co.uk> Content-Type: text/plain; charset=us-ascii; 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: LOCK refresh on indirectly locked resource X-Archived-At: http://www.w3.org/mid/41456680.4020108@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8824 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 Sep 2004 10:21:39 +0000 Content-Transfer-Encoding: 7bit Joe Orton wrote: > On Sun, Sep 12, 2004 at 07:39:43PM +0200, Julian Reschke wrote: > >>It's some time ago that somebody asked how servers implement this today. >>I finally got around to write a test case (attached JScript), including >> >>1) using a no-tag list If header, >>2) using a tagged If header, specifying the lock root and >>2) using a tagged If header, specifying the indirectly locked resource. > > > Is your latter (2) behaviour defined by 2518 or 2518bis? I suppose both > are equivalent by 2518 at least. I don't think RFC2518 defines any of these. This is why we were trying to find out what servers actually *do* implement, so that it can be clarified in RFC2518bis. IMHO, nobody seems to be doing this in practice (otherwise the bug in mod_dav would have surfaced earlier); thus RFC2518bis probably should say that you can't do a LOCK refresh that way. >>Results: > > ... > >>Apache2.0.50/mod_dav: *crashes*, see >> > > > It looks like the code path for indirectly refreshing the lock had never > been tested in mod_dav, it has never worked AFAICT. I can't find any > reports of this bug being triggered before, either, so I guess this is > not the most widely used protocol feature... Yep. > (I've made a new release of the litmus test suite which also includes a > test for an indirect lock refresh for any others who are interested and > can't run JScript: http://www.webdav.org/neon/litmus/) Thanks, Joe. Your work on Neon and Litmus is a really a big contribution to WebDAV. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 13 12:04: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 MAA12085 for ; Mon, 13 Sep 2004 12:04:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6tIV-0001fI-EA; Mon, 13 Sep 2004 16:03:19 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C6tIU-0001dw-NU for w3c-dist-auth@listhub.w3.org; Mon, 13 Sep 2004 16:03:18 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by bart.w3.org with esmtp (Exim 4.34) id 1C6tIU-00044w-Et for w3c-dist-auth@w3.org; Mon, 13 Sep 2004 16:03:18 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i8DG5oht027423 for ; Mon, 13 Sep 2004 09:05:50 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Mon, 13 Sep 2004 09:02:46 -0700 Received: from [17.202.43.76] (luthji.apple.com [17.202.43.76]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id i8DG2ipg020833 for ; Mon, 13 Sep 2004 09:02:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v673) Content-Transfer-Encoding: 7bit Message-Id: <58BB3662-059E-11D9-A08C-000A95DC65E0@apple.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: w3c-dist-auth@w3.org From: Jim Luther Date: Mon, 13 Sep 2004 09:02:43 -0700 X-Mailer: Apple Mail (2.673) Received-SPF: pass (bart.w3.org: domain of luther.j@apple.com designates 17.254.13.22 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: rfc2518bis Safe Methods vs Redirection issue X-Archived-At: http://www.w3.org/mid/58BB3662-059E-11D9-A08C-000A95DC65E0@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8825 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 Sep 2004 16:03:19 +0000 Content-Transfer-Encoding: 7bit In the HTTP/1.1 Specification Errata there is a section titled "Safe Methods vs Redirection" which concludes with "It would also be helpful for each of the method definition sections to specifically define whether or not the method is safe. OPTIONS, GET, and HEAD are all safe in RFC 2616. HTTP extensions like WebDAV define additional safe methods." I don't see anywhere in rfc2518 or rfc2518bis where WebDAV methods are defined as safe or unsafe. rfc2518bis should probably state which WebDAV methods are safe and which are unsafe. In my code, I'm assuming PROPFIND is a safe method and that PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK are unsafe methods by the definitions in rfc2616, section 9.1.1 "Safe Methods". Does that sound right to the working group? - Jim From w3c-dist-auth-request@w3.org Mon Sep 13 12:11: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 MAA13211 for ; Mon, 13 Sep 2004 12:11:02 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6tPW-0004jT-HD; Mon, 13 Sep 2004 16:10:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C6tPV-0004ix-Uw for w3c-dist-auth@listhub.w3.org; Mon, 13 Sep 2004 16:10:33 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C6tPU-0005ty-3C for w3c-dist-auth@w3.org; Mon, 13 Sep 2004 16:10:32 +0000 Received: (qmail 28677 invoked by uid 65534); 13 Sep 2004 16:09:58 -0000 Received: from p50825320.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.83.32) by mail.gmx.net (mp022) with SMTP; 13 Sep 2004 18:09:58 +0200 X-Authenticated: #1915285 Message-ID: <4145C651.6040301@gmx.de> Date: Mon, 13 Sep 2004 18:09:53 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Luther CC: w3c-dist-auth@w3.org References: <58BB3662-059E-11D9-A08C-000A95DC65E0@apple.com> In-Reply-To: <58BB3662-059E-11D9-A08C-000A95DC65E0@apple.com> Content-Type: text/plain; charset=us-ascii; 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: rfc2518bis Safe Methods vs Redirection issue X-Archived-At: http://www.w3.org/mid/4145C651.6040301@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8826 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 Sep 2004 16:10:34 +0000 Content-Transfer-Encoding: 7bit Jim Luther wrote: > > In the HTTP/1.1 Specification Errata > there is a section titled "Safe Methods vs Redirection" which concludes > with "It would also be helpful for each of the method definition > sections to specifically define whether or not the method is safe. > OPTIONS, GET, and HEAD are all safe in RFC 2616. HTTP extensions like > WebDAV define additional safe methods." > > I don't see anywhere in rfc2518 or rfc2518bis where WebDAV methods are > defined as safe or unsafe. rfc2518bis should probably state which WebDAV > methods are safe and which are unsafe. > > In my code, I'm assuming PROPFIND is a safe method and that PROPPATCH, > MKCOL, COPY, MOVE, LOCK, and UNLOCK are unsafe methods by the > definitions in rfc2616, section 9.1.1 "Safe Methods". Does that sound > right to the working group? Sounds right to me. This a probably a to-do for the issues lists for RFC3253, RFC3648 and RFC3744 as well. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 13 14:15: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 OAA22513 for ; Mon, 13 Sep 2004 14:15:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6vM0-0007cT-JP; Mon, 13 Sep 2004 18:15:04 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C6vLz-0007bh-Vg for w3c-dist-auth@listhub.w3.org; Mon, 13 Sep 2004 18:15:03 +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 1C6vLz-0001xA-Pl for w3c-dist-auth@w3.org; Mon, 13 Sep 2004 18:15:03 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Sep 2004 11:14:29 -0700 In-Reply-To: <41357711.1080309@gmx.de> References: <41357711.1080309@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Brian Korver Date: Mon, 13 Sep 2004 11:14:28 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 13 Sep 2004 18:14:29.0783 (UTC) FILETIME=[82EFAA70:01C499BD] 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/C0825801-05B0-11D9-918D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8827 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 Sep 2004 18:15:04 +0000 Content-Transfer-Encoding: 7bit Julian, I think that the MUST and MUST NOT in the following should really be must and must not, in other words: 5.1 Marshalling of datatype information PROPFIND is extended to return the data type information for properties unless one of the following conditions is met: o The data type must be different from "xs:string" (because this can be considered the default data type). o The property's data type must not be defined in [RFC2518] (because these types are already well-defined). -brian briank@xythos.com On Sep 1, 2004, at 12:15 AM, Julian Reschke wrote: > > Hi, > > I just submitted draft 07 of draft-reschke-webdav-property-datatypes: > > datatypes-07.txt> > > As previously announced, this draft removes the definition of various > property flags and DASL extensions, concentrating on the core property > datatyping as implemented / being implemented in SAP's Enterprise > Portal and SAP Netweaver, and Xythos WebFile Server. > > This part of the spec has been stable for several years now, and as > far as I can tell, the WebDAV working group currently lacks the time > to transform this into a Working Group activity. On the other hand, > this work not only is implemented in shipping products, it should also > be valuable for anybody looking at adding typing to WebDAV properties. > Thus, it probably makes sense for it being published by the IETF, > either as experimental or proposed protocol. > > I hereby invite all readers to review the spec (both for content and > editorial aspects). Unless no new issues are raised, I plan to > last-call it and then submit it to the IESG as a private submission. > I'd also appreciate feedback on which publication status > (experimental/proposed) I should target. > > Note that those sections that were removed (see change information in > datatypes-07.html>) will later appear in a separate draft built on top > of the core property types spec. > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > From w3c-dist-auth-request@w3.org Mon Sep 13 18:03: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 SAA17597 for ; Mon, 13 Sep 2004 18:03:11 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6yu3-00007H-90; Mon, 13 Sep 2004 22:02:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C6yu2-00006D-B6 for w3c-dist-auth@listhub.w3.org; Mon, 13 Sep 2004 22:02:26 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C6yu0-0001e1-IT for w3c-dist-auth@w3.org; Mon, 13 Sep 2004 22:02:24 +0000 Received: (qmail 32760 invoked by uid 65534); 13 Sep 2004 22:01:52 -0000 Received: from p54856D01.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.109.1) by mail.gmx.net (mp010) with SMTP; 14 Sep 2004 00:01:52 +0200 X-Authenticated: #1915285 Message-ID: <414618CD.6030507@gmx.de> Date: Tue, 14 Sep 2004 00:01:49 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: w3c-dist-auth@w3.org References: <41357711.1080309@gmx.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/414618CD.6030507@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8828 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 Sep 2004 22:02:27 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > > Julian, > > I think that the MUST and MUST NOT in the following should really > be must and must not, in other words: > > 5.1 Marshalling of datatype information > > PROPFIND is extended to return the data type information for > properties unless one of the following conditions is met: > > o The data type must be different from "xs:string" (because this can > be considered the default data type). > > o The property's data type must not be defined in [RFC2518] (because > these types are already well-defined). > > -brian > briank@xythos.com Brian, good catch; I'll make that change and will also check for more places where we aren't specific enough. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 13 18: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 SAA17921 for ; Mon, 13 Sep 2004 18:05:45 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6ywl-00017z-P6; Mon, 13 Sep 2004 22:05:15 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C6ywl-00017T-IO for w3c-dist-auth@listhub.w3.org; Mon, 13 Sep 2004 22:05:15 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1C6ywj-0001zt-T2 for w3c-dist-auth@w3.org; Mon, 13 Sep 2004 22:05: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 i8DM4ppp009718 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 13 Sep 2004 15:04:52 -0700 In-Reply-To: <414351A2.2080505@gmx.de> References: <414351A2.2080505@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: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Mon, 13 Sep 2004 15:04:41 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (lisa.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Issues with rfc2518bis-06 (part 3) X-Archived-At: http://www.w3.org/mid/E9975BAD-05D0-11D9-9C6B-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8829 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 Sep 2004 22:05:15 +0000 Content-Transfer-Encoding: 7bit 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 From w3c-dist-auth-request@w3.org Mon Sep 13 18:07: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 SAA18215 for ; Mon, 13 Sep 2004 18:07:26 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6yyQ-0001dY-If; Mon, 13 Sep 2004 22:06:58 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C6yyQ-0001d2-8j for w3c-dist-auth@listhub.w3.org; Mon, 13 Sep 2004 22:06:58 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C6yyP-0005fZ-UY for w3c-dist-auth@w3.org; Mon, 13 Sep 2004 22:06:58 +0000 Received: (qmail 29787 invoked by uid 65534); 13 Sep 2004 22:06:25 -0000 Received: from p54856D01.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.109.1) by mail.gmx.net (mp008) with SMTP; 14 Sep 2004 00:06:25 +0200 X-Authenticated: #1915285 Message-ID: <414619DE.5050300@gmx.de> Date: Tue, 14 Sep 2004 00:06:22 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: w3c-dist-auth@w3.org References: <41357711.1080309@gmx.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/414619DE.5050300@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8830 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 Sep 2004 22:06:58 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > Julian, > > I think that the MUST and MUST NOT in the following should really > be must and must not, in other words: > > 5.1 Marshalling of datatype information > > PROPFIND is extended to return the data type information for > properties unless one of the following conditions is met: > > o The data type must be different from "xs:string" (because this can > be considered the default data type). > > o The property's data type must not be defined in [RFC2518] (because > these types are already well-defined). > > -brian > briank@xythos.com OK, I got that backwards. Why do you think they should be lowercase? Are you anticipating servers that either do not want or can't implement it exactly that way? If so, why? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 13 18:10: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 SAA18738 for ; Mon, 13 Sep 2004 18:10:46 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6z1e-0002nh-EY; Mon, 13 Sep 2004 22:10:18 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C6z1d-0002nB-JM for w3c-dist-auth@listhub.w3.org; Mon, 13 Sep 2004 22:10:17 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C6z1d-0006BJ-8A for w3c-dist-auth@w3.org; Mon, 13 Sep 2004 22:10:17 +0000 Received: (qmail 8480 invoked by uid 65534); 13 Sep 2004 22:09:45 -0000 Received: from p54856D01.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.109.1) by mail.gmx.net (mp026) with SMTP; 14 Sep 2004 00:09:45 +0200 X-Authenticated: #1915285 Message-ID: <41461AA1.5010500@gmx.de> Date: Tue, 14 Sep 2004 00:09:37 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: w3c-dist-auth@w3.org References: <414351A2.2080505@gmx.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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: Issues with rfc2518bis-06 (part 3) X-Archived-At: http://www.w3.org/mid/41461AA1.5010500@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8831 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 Sep 2004 22:10:18 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > 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. I do appreciate the plan to enhance the issue tracking. May I recommend to simply adopt what I've been doing in the drafts I am / was editing (which means embedding the issue inside the xml2rfc draft text using XML extension elements)? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 13 18:16: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 SAA19459 for ; Mon, 13 Sep 2004 18:16:16 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6z6w-0004GG-6f; Mon, 13 Sep 2004 22:15:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C6z6u-0004Ff-Ow for w3c-dist-auth@listhub.w3.org; Mon, 13 Sep 2004 22:15:44 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1C6z6s-0003Gx-W6 for w3c-dist-auth@w3.org; Mon, 13 Sep 2004 22:15:43 +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 i8DMFLpp010223 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 13 Sep 2004 15:15:21 -0700 In-Reply-To: <41461AA1.5010500@gmx.de> References: <414351A2.2080505@gmx.de> <41461AA1.5010500@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <60900058-05D2-11D9-9C6B-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Mon, 13 Sep 2004 15:15:10 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (lisa.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Issues with rfc2518bis-06 (part 3) X-Archived-At: http://www.w3.org/mid/60900058-05D2-11D9-9C6B-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8832 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 Sep 2004 22:15:46 +0000 Content-Transfer-Encoding: 7bit I find that unacceptable for WG-tracked issues (of course it's fine for the author's own issues or to duplicate the WG-tracked issues until the author believes they've dealt with them). The author can close the issues in their document as soon as they've made changes, but for many issues there needs to be some external item for the issues tracker person to mark state on when the WG agrees the issue is actually closed. Lisa On Sep 13, 2004, at 3:09 PM, Julian Reschke wrote: > Lisa Dusseault wrote: > >> 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. > > I do appreciate the plan to enhance the issue tracking. May I > recommend to simply adopt what I've been doing in the drafts I am / > was editing (which means embedding the issue inside the xml2rfc draft > text using XML extension elements)? > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 13 18:39: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 SAA21456 for ; Mon, 13 Sep 2004 18:39:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C6zTc-0001LV-Gh; Mon, 13 Sep 2004 22:39:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C6zTb-0001Kz-A6 for w3c-dist-auth@listhub.w3.org; Mon, 13 Sep 2004 22:39:11 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1C6zTZ-0005Uy-HN for w3c-dist-auth@w3.org; Mon, 13 Sep 2004 22:39:09 +0000 Received: (qmail 1376 invoked by uid 65534); 13 Sep 2004 22:38:39 -0000 Received: from p54856D01.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.109.1) by mail.gmx.net (mp026) with SMTP; 14 Sep 2004 00:38:39 +0200 X-Authenticated: #1915285 Message-ID: <4146216C.9020800@gmx.de> Date: Tue, 14 Sep 2004 00:38:36 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: w3c-dist-auth@w3.org References: <414351A2.2080505@gmx.de> <41461AA1.5010500@gmx.de> <60900058-05D2-11D9-9C6B-000A95B2BB72@osafoundation.org> In-Reply-To: <60900058-05D2-11D9-9C6B-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=us-ascii; 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: Issues tracking, Re: Issues with rfc2518bis-06 (part 3) X-Archived-At: http://www.w3.org/mid/4146216C.9020800@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8833 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 Sep 2004 22:39:12 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I find that unacceptable for WG-tracked issues (of course it's fine for > the author's own issues or to duplicate the WG-tracked issues until the > author believes they've dealt with them). The author can close the > issues in their document as soon as they've made changes, but for many > issues there needs to be some external item for the issues tracker > person to mark state on when the WG agrees the issue is actually closed. I do agree that an issue isn't automatically closed just because the document editor thinks it is. But that doesn't seem to be a big issue -- give change control to somebody else as well, or have the author not close issues before there's WG consensus. IMHO this has worked just fine for previous drafts, though. The document editor makes a proposal about how to resolve a specific issue to the mailing list, and does so in the working document (with the expectation that the change needs to be rolled back if the change turns out not to be ok). The big advantages of having everything in one place are: - document and issues list are in sync *by definition* - published Internet Drafts automatically carry a list of open and resolved issues Just my 2 cents, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 13 19:57: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 TAA26751 for ; Mon, 13 Sep 2004 19:57:18 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C70gf-0007v5-Pj; Mon, 13 Sep 2004 23:56:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C70ge-0007tA-U7 for w3c-dist-auth@listhub.w3.org; Mon, 13 Sep 2004 23:56:44 +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 1C70gd-00071h-An for w3c-dist-auth@w3.org; Mon, 13 Sep 2004 23:56:43 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Sep 2004 16:56:10 -0700 In-Reply-To: <414619DE.5050300@gmx.de> References: <41357711.1080309@gmx.de> <414619DE.5050300@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7DCC1284-05E0-11D9-918D-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Brian Korver Date: Mon, 13 Sep 2004 16:56:12 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 13 Sep 2004 23:56:10.0876 (UTC) FILETIME=[3E8A33C0:01C499ED] 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/7DCC1284-05E0-11D9-918D-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8834 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 Sep 2004 23:56:45 +0000 Content-Transfer-Encoding: 7bit Because these are conditions describing the state of the world, not (in this context) mandates on server behavior. -brian briank@xythos.com On Sep 13, 2004, at 3:06 PM, Julian Reschke wrote: > Brian Korver wrote: > >> Julian, >> I think that the MUST and MUST NOT in the following should really >> be must and must not, in other words: >> 5.1 Marshalling of datatype information >> PROPFIND is extended to return the data type information for >> properties unless one of the following conditions is met: >> o The data type must be different from "xs:string" (because this >> can >> be considered the default data type). >> o The property's data type must not be defined in [RFC2518] >> (because >> these types are already well-defined). >> -brian >> briank@xythos.com > > OK, I got that backwards. > > Why do you think they should be lowercase? Are you anticipating > servers that either do not want or can't implement it exactly that > way? If so, why? > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Mon Sep 13 20:17: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 UAA27832 for ; Mon, 13 Sep 2004 20:17:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C710F-0007DA-Ge; Tue, 14 Sep 2004 00:16:59 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C710E-0007Ca-Ux for w3c-dist-auth@listhub.w3.org; Tue, 14 Sep 2004 00:16:58 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1C710E-0001Vc-Jm for w3c-dist-auth@w3.org; Tue, 14 Sep 2004 00:16:58 +0000 Received: (qmail 7956 invoked by uid 65534); 14 Sep 2004 00:16:26 -0000 Received: from p54856D01.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.109.1) by mail.gmx.net (mp003) with SMTP; 14 Sep 2004 02:16:26 +0200 X-Authenticated: #1915285 Message-ID: <41463853.3020503@gmx.de> Date: Tue, 14 Sep 2004 02:16:19 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: w3c-dist-auth@w3.org References: <41357711.1080309@gmx.de> <414619DE.5050300@gmx.de> <7DCC1284-05E0-11D9-918D-000A95AACED2@xythos.com> In-Reply-To: <7DCC1284-05E0-11D9-918D-000A95AACED2@xythos.com> Content-Type: text/plain; charset=us-ascii; 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/41463853.3020503@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8835 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 Sep 2004 00:16:59 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > > Because these are conditions describing the state > of the world, not (in this context) mandates on > server behavior. Yes, they are. It says exactly when the server behaviour gets extended (when the type isn't "simple string" *and* if the property isn't defined in RFC2518). Can you suggest alternative wording that keeps the RFC2119 terminology? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Sep 14 13:53: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 NAA29782 for ; Tue, 14 Sep 2004 13:53:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7HU0-0001YS-Fw; Tue, 14 Sep 2004 17:52:48 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C7HTz-0001Xe-Od for w3c-dist-auth@listhub.w3.org; Tue, 14 Sep 2004 17:52:47 +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 1C7HTz-0006KD-J7 for w3c-dist-auth@w3.org; Tue, 14 Sep 2004 17:52:47 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Sep 2004 10:52:16 -0700 In-Reply-To: <41463853.3020503@gmx.de> References: <41357711.1080309@gmx.de> <414619DE.5050300@gmx.de> <7DCC1284-05E0-11D9-918D-000A95AACED2@xythos.com> <41463853.3020503@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Brian Korver Date: Tue, 14 Sep 2004 10:52:11 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 14 Sep 2004 17:52:16.0104 (UTC) FILETIME=[926A2680:01C49A83] 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/CE26F4DA-0676-11D9-BD73-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8836 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 Sep 2004 17:52:48 +0000 Content-Transfer-Encoding: 7bit On Sep 13, 2004, at 5:16 PM, Julian Reschke wrote: > Brian Korver wrote: >> Because these are conditions describing the state >> of the world, not (in this context) mandates on >> server behavior. > > Yes, they are. > > It says exactly when the server behaviour gets extended (when the type > isn't "simple string" *and* if the property isn't defined in RFC2518). > > Can you suggest alternative wording that keeps the RFC2119 > terminology? > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 Julian, I'm officially confused. Your text states that they are conditions ("the following conditions"), but you claim here that they're not. Anyhow, not worth arguing about.... -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Sep 14 14:06: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 OAA01011 for ; Tue, 14 Sep 2004 14:06:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7Hgu-0005IT-6a; Tue, 14 Sep 2004 18:06:08 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C7Hgt-0005Hx-No for w3c-dist-auth@listhub.w3.org; Tue, 14 Sep 2004 18:06:07 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1C7Hgt-0008LI-FU for w3c-dist-auth@w3.org; Tue, 14 Sep 2004 18:06:07 +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 i8EI5jpp016389 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 14 Sep 2004 11:05:46 -0700 In-Reply-To: <41357711.1080309@gmx.de> References: <41357711.1080309@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: Bernard Desruisseaux , webdav From: Lisa Dusseault Date: Tue, 14 Sep 2004 11:05:38 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (bart.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/AEC9E3C6-0678-11D9-9C6B-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8837 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 Sep 2004 18:06:08 +0000 Content-Transfer-Encoding: 7bit I have a nit on the draft: the example shows a boolean value of '1' in section 5.1, but the text below says this is a value of 'true'. More globally, some issues: - I had some understanding from previous discussions that this was supposed to allow multi-valued properties. However, it appears that the entire property value must be provided in each PROPPATCH request. It would be helpful if the specification communicated this. - I'm a little concerned that the multi-valued stuff is in an appendix. If this functionality MUST be supported (by servers that support the draft) then the examples should be in the main text, so that server implementors aren't tempted not to support it. - The draft should make more explicit requirements on server implementors, to help ensure more interoperable and consistent implementations. For example, the draft should say something along the lines of "Servers supporting this feature MUST support the following list of data types and the array data type... [etc] " - Should there be a way for clients to detect whether the server supports this feature? I would think that would be better. However, if there's no way, then there should be some guidance for clients along the lines of "If the client supports this draft, the client SHOULD send data typing information for all non-string data types, without even knowing whether the server supports the feature." Lisa On Sep 1, 2004, at 12:15 AM, Julian Reschke wrote: > > Hi, > > I just submitted draft 07 of draft-reschke-webdav-property-datatypes: > > datatypes-07.txt> > > As previously announced, this draft removes the definition of various > property flags and DASL extensions, concentrating on the core property > datatyping as implemented / being implemented in SAP's Enterprise > Portal and SAP Netweaver, and Xythos WebFile Server. > > This part of the spec has been stable for several years now, and as > far as I can tell, the WebDAV working group currently lacks the time > to transform this into a Working Group activity. On the other hand, > this work not only is implemented in shipping products, it should also > be valuable for anybody looking at adding typing to WebDAV properties. > Thus, it probably makes sense for it being published by the IETF, > either as experimental or proposed protocol. > > I hereby invite all readers to review the spec (both for content and > editorial aspects). Unless no new issues are raised, I plan to > last-call it and then submit it to the IESG as a private submission. > I'd also appreciate feedback on which publication status > (experimental/proposed) I should target. > > Note that those sections that were removed (see change information in > datatypes-07.html>) will later appear in a separate draft built on top > of the core property types spec. > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > From w3c-dist-auth-request@w3.org Tue Sep 14 16:57: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 QAA20154 for ; Tue, 14 Sep 2004 16:57:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7KM9-00046m-LB; Tue, 14 Sep 2004 20:56:53 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C7KM8-00046B-QS for w3c-dist-auth@listhub.w3.org; Tue, 14 Sep 2004 20:56:52 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C7KM8-0004XM-Ba for w3c-dist-auth@w3.org; Tue, 14 Sep 2004 20:56:52 +0000 Received: (qmail 24969 invoked by uid 65534); 14 Sep 2004 20:56:18 -0000 Received: from p54856D01.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.109.1) by mail.gmx.net (mp020) with SMTP; 14 Sep 2004 22:56:18 +0200 X-Authenticated: #1915285 Message-ID: <41475AF0.2020102@gmx.de> Date: Tue, 14 Sep 2004 22:56:16 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: w3c-dist-auth@w3.org References: <41357711.1080309@gmx.de> <414619DE.5050300@gmx.de> <7DCC1284-05E0-11D9-918D-000A95AACED2@xythos.com> <41463853.3020503@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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/41475AF0.2020102@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8838 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 Sep 2004 20:56:53 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > On Sep 13, 2004, at 5:16 PM, Julian Reschke wrote: > >> Brian Korver wrote: >> >>> Because these are conditions describing the state >>> of the world, not (in this context) mandates on >>> server behavior. >> >> >> Yes, they are. >> >> It says exactly when the server behaviour gets extended (when the type >> isn't "simple string" *and* if the property isn't defined in RFC2518). >> >> Can you suggest alternative wording that keeps the RFC2119 terminology? >> >> Best regards, Julian >> >> -- >> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > Julian, > > I'm officially confused. Your text states that they > are conditions ("the following conditions"), but you > claim here that they're not. Anyhow, not worth arguing > about.... Brian, I still don't get your point. The text clearly defines under which conditions the server should return datatype information. Do you have any proposal how to rephrase that? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Sep 14 17:06: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 RAA20844 for ; Tue, 14 Sep 2004 17:06:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7KV4-0007gT-Kx; Tue, 14 Sep 2004 21:06:06 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C7KV4-0007fa-D0 for w3c-dist-auth@listhub.w3.org; Tue, 14 Sep 2004 21:06:06 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C7KV2-0001x2-Hx for w3c-dist-auth@w3.org; Tue, 14 Sep 2004 21:06:04 +0000 Received: (qmail 28856 invoked by uid 65534); 14 Sep 2004 21:05:33 -0000 Received: from p54856D01.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.109.1) by mail.gmx.net (mp012) with SMTP; 14 Sep 2004 23:05:33 +0200 X-Authenticated: #1915285 Message-ID: <41475D14.6000303@gmx.de> Date: Tue, 14 Sep 2004 23:05:24 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Bernard Desruisseaux , webdav References: <41357711.1080309@gmx.de> 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/41475D14.6000303@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8839 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 Sep 2004 21:06:06 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > I have a nit on the draft: the example shows a boolean value of '1' in > section 5.1, but the text below says this is a value of 'true'. The *typed* value is the same. Both "1" and "true" are legal serializations of the XML Schema datatype "boolean". > More globally, some issues: > - I had some understanding from previous discussions that this was > supposed to allow multi-valued properties. However, it appears that > the entire property value must be provided in each PROPPATCH request. > It would be helpful if the specification communicated this. Well, the spec doesn't change basic PROPPATCH semantics (and it never was claimed it does). Does it really need to state that it doesn't? Why? > - I'm a little concerned that the multi-valued stuff is in an > appendix. If this functionality MUST be supported (by servers that > support the draft) then the examples should be in the main text, so > that server implementors aren't tempted not to support it. No, it's an appendix because it's entirely optional. All that the spec defines is how you can use the xsi:type attribute from XML Schema to forward type information. It doesn't mandate support for any specific types. > - The draft should make more explicit requirements on server > implementors, to help ensure more interoperable and consistent > implementations. For example, the draft should say something along the > lines of "Servers supporting this feature MUST support the following > list of data types and the array data type... [etc] " See above, they don't have to. Is there any hope that we can get a consensus of a minimum set? I guess it wouldn't contain more than strings, dates and integers (I wouldn't even expect boolean support from everybody). > - Should there be a way for clients to detect whether the server > supports this feature? I would think that would be better. However, The client can detect that by looking at PROPFIND and PROPPATCH responses. > if there's no way, then there should be some guidance for clients along > the lines of "If the client supports this draft, the client SHOULD send > data typing information for all non-string data types, without even > knowing whether the server supports the feature." Section 6 () states that it's harmless to provide data type information upon PROPPATCH. Is there any need to expand this? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Sep 14 17:23: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 RAA22675 for ; Tue, 14 Sep 2004 17:23:36 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7KlW-00058n-6p; Tue, 14 Sep 2004 21:23:06 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C7KlV-00058H-Ma for w3c-dist-auth@listhub.w3.org; Tue, 14 Sep 2004 21:23: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 1C7KlU-00052p-03 for w3c-dist-auth@w3.org; Tue, 14 Sep 2004 21:23:04 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Sep 2004 14:22:32 -0700 In-Reply-To: <41475AF0.2020102@gmx.de> References: <41357711.1080309@gmx.de> <414619DE.5050300@gmx.de> <7DCC1284-05E0-11D9-918D-000A95AACED2@xythos.com> <41463853.3020503@gmx.de> <41475AF0.2020102@gmx.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3070436F-0694-11D9-BD73-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Brian Korver Date: Tue, 14 Sep 2004 14:22:32 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 14 Sep 2004 21:22:32.0042 (UTC) FILETIME=[F21984A0:01C49AA0] 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/3070436F-0694-11D9-BD73-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8840 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 Sep 2004 21:23:06 +0000 Content-Transfer-Encoding: 7bit On Sep 14, 2004, at 1:56 PM, Julian Reschke wrote: > Brian, I still don't get your point. The text clearly defines under > which conditions the server should return datatype information. Do you > have any proposal how to rephrase that? > > Best regards, Julian > Julian, It doesn't need rephrasing. I think the capitalization needs to be changed (from upper to lower), but the text is clear (if a little jarring) without that change so it really doesn't matter. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Sep 14 18:36: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 SAA00992 for ; Tue, 14 Sep 2004 18:36:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7Lto-00040p-1r; Tue, 14 Sep 2004 22:35:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C7Ltn-00040H-0A for w3c-dist-auth@listhub.w3.org; Tue, 14 Sep 2004 22:35:43 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1C7Ltl-0005Wa-7q for w3c-dist-auth@w3.org; Tue, 14 Sep 2004 22:35:41 +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 i8EMZVpp027057 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 14 Sep 2004 15:35:32 -0700 In-Reply-To: <41475D14.6000303@gmx.de> References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Bernard Desruisseaux , webdav From: Lisa Dusseault Date: Tue, 14 Sep 2004 15:35:22 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (lisa.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8841 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 Sep 2004 22:35:44 +0000 Content-Transfer-Encoding: 7bit Responses inline... On Sep 14, 2004, at 2:05 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> I have a nit on the draft: the example shows a boolean value of '1' >> in section 5.1, but the text below says this is a value of 'true'. > > The *typed* value is the same. Both "1" and "true" are legal > serializations of the XML Schema datatype "boolean". It seemed like a bug to me, so maybe the example needs more explanation. > >> More globally, some issues: >> - I had some understanding from previous discussions that this was >> supposed to allow multi-valued properties. However, it appears that >> the entire property value must be provided in each PROPPATCH request. >> It would be helpful if the specification communicated this. > > Well, the spec doesn't change basic PROPPATCH semantics (and it never > was claimed it does). Does it really need to state that it doesn't? > Why? Only a matter of setting expectations -- what this spec does provide, what it doesn't provide. Human-readable overview text to provide context for how to consider this work. > >> - I'm a little concerned that the multi-valued stuff is in an >> appendix. If this functionality MUST be supported (by servers that >> support the draft) then the examples should be in the main text, so >> that server implementors aren't tempted not to support it. > > No, it's an appendix because it's entirely optional. All that the spec > defines is how you can use the xsi:type attribute from XML Schema to > forward type information. It doesn't mandate support for any specific > types. If it were going to the regular standards track I'd strongly push for a list of mandated types to support. Since you're proposing this for the experimental track, I suppose it can be conceptualized as a description of the way an implementor might do things with very little (nothing?) in the draft being required. One consequence of having weak or no requirements, and no advertisement of the feature, you might find that it's difficult to get critical mass of support for this stuff, beyond the implementations that already support this or something of the kind. > >> - The draft should make more explicit requirements on server >> implementors, to help ensure more interoperable and consistent >> implementations. For example, the draft should say something along >> the lines of "Servers supporting this feature MUST support the >> following list of data types and the array data type... [etc] " > > See above, they don't have to. Is there any hope that we can get a > consensus of a minimum set? I guess it wouldn't contain more than > strings, dates and integers (I wouldn't even expect boolean support > from everybody). Depending on the concept for the document, I would go so far as to propose that all the built-in primitive types would be required, possibly also integer and a few of the integer-derived types. Also the server would be required to support lists of any of the supported types. > >> if there's no way, then there should be some guidance for clients >> along the lines of "If the client supports this draft, the client >> SHOULD send data typing information for all non-string data types, >> without even knowing whether the server supports the feature." > > Section 6 > ( datatypes-latest.html#rfc.section.6>) states that it's harmless to > provide data type information upon PROPPATCH. Is there any need to > expand this? Depends on how readable you want the spec to be. I would consider that information very helpful and clarifying. Lisa From w3c-dist-auth-request@w3.org Wed Sep 15 06:02: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 GAA18434 for ; Wed, 15 Sep 2004 06:02:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7WbM-00036Q-Qh; Wed, 15 Sep 2004 10:01:24 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C7WbM-00035o-0g for w3c-dist-auth@listhub.w3.org; Wed, 15 Sep 2004 10:01:24 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C7WbL-0005nO-O4 for w3c-dist-auth@w3.org; Wed, 15 Sep 2004 10:01:23 +0000 Received: (qmail 22350 invoked by uid 65534); 15 Sep 2004 10:00:51 -0000 Received: from p50824B4B.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.75.75) by mail.gmx.net (mp015) with SMTP; 15 Sep 2004 12:00:51 +0200 X-Authenticated: #1915285 Message-ID: <414812D2.60609@gmx.de> Date: Wed, 15 Sep 2004 12:00:50 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Bernard Desruisseaux , webdav References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> In-Reply-To: <5D6773F4-069E-11D9-9C6B-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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/414812D2.60609@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8842 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, 15 Sep 2004 10:01:24 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Responses inline... > > On Sep 14, 2004, at 2:05 PM, Julian Reschke wrote: > >> Lisa Dusseault wrote: >> >>> I have a nit on the draft: the example shows a boolean value of '1' >>> in section 5.1, but the text below says this is a value of 'true'. >> >> >> The *typed* value is the same. Both "1" and "true" are legal >> serializations of the XML Schema datatype "boolean". > > > It seemed like a bug to me, so maybe the example needs more explanation. It currently says: "This example shows that the property value "true" is returned with the correct data type information, and that the server chose one of the two possible representations defined in XML Schema." Can you suggest a change? I think it's already clear enough... > ... > Depending on the concept for the document, I would go so far as to > propose that all the built-in primitive types would be required, All of ??? Including things like all these specific date/duration formats? > possibly also integer and a few of the integer-derived types. Also the Integers *are* builtin types. > server would be required to support lists of any of the supported types. 1) I can easily imagine servers that do not support array-typed properties, and 2) even if they do, that would require the spec to make a normative statement about the format; the current format implented by us and described in the appendis is based on SOAP 1.1; and I'm sure many would prefer to avoid any SOAP dependencies. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Sep 15 08:05: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 IAA25480 for ; Wed, 15 Sep 2004 08:05:20 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7YWk-0004pm-NV; Wed, 15 Sep 2004 12:04:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C7YWj-0004pE-VZ; Wed, 15 Sep 2004 12:04:45 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.103]) by lisa.w3.org with esmtp (Exim 4.34) id 1C7YWi-0008CJ-4k; Wed, 15 Sep 2004 12:04:44 +0000 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8FC4ERK611654; Wed, 15 Sep 2004 08:04:14 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8FC5RxF150078; Wed, 15 Sep 2004 08:05:27 -0400 In-Reply-To: To: " webdav" Cc: "'ietf-dav-versioning@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, 15 Sep 2004 08:04:05 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF535 | September 3, 2004) at 09/15/2004 08:04:13, Serialize complete at 09/15/2004 08:04:13 Content-Type: multipart/alternative; boundary="=_alternative 00424B4A85256F10_=" 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: succeed code for DELETE X-Archived-At: http://www.w3.org/mid/OF04524763.0F466FBE-ON85256F10.0041B0BA-85256F10.00424B4C@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8843 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, 15 Sep 2004 12:04:46 +0000 This is a multipart message in MIME format. --=_alternative 00424B4A85256F10_= Content-Type: text/plain; charset="US-ASCII" Good catch, Girish! RFC-2518bis team: Please add this to the list of editorial issues for 2518. These two sentences in 8.6 (in 8.7 of 2518bis) should be deleted. The first sentence is wrong, because 204 is not an error, and so there is no such thing as a "204 (No Content) error". The second sentence is wrong, because 204 (No Content) is not the "default success code". Cheers, Geoff Girish wrote on 09/15/2004 02:58:50 AM: > At the end of section 8.6 (DELETE), there is a statement which > states that 204 should not be included in a 207. > "Additionally 204 (No Content) errors SHOULD NOT be returned in > the 207 (Multi-Status).The reason for this prohibition is that > 204 (No Content) is the default success code." > It was this particular phrase which confused me. > Girish wrote on 09/14/2004 10:42:32 AM: > > Can a successful DELETE (in my case, deletion of a version-history) > > return some content (some href, for example) to the client? > > RFC 2158 states that 204 (no content) is the default success code > > for DELETE. I was wondering if there are special deltaV semantics. --=_alternative 00424B4A85256F10_= Content-Type: text/html; charset="US-ASCII"
Good catch, Girish!

RFC-2518bis team: Please add this to the list of editorial issues
for 2518.

These two sentences in 8.6 (in 8.7 of 2518bis) should be deleted.
The first sentence is wrong, because 204 is not an error, and so
there is no such thing as a "204 (No Content) error".
The second sentence is wrong, because 204 (No Content) is not
the "default success code".

Cheers,
Geoff

Girish wrote on 09/15/2004 02:58:50 AM:
> At the end of section 8.6 (DELETE), there is a statement which
> states that 204 should not be included in a 207.
> "Additionally 204 (No Content) errors SHOULD NOT be returned in
> the 207 (Multi-Status).The reason for this prohibition is that
> 204 (No Content) is the default success code."
> It was this particular phrase which confused me.

>    Girish wrote on 09/14/2004 10:42:32 AM:
>    > Can a successful DELETE (in my case, deletion of a version-history)
>    > return some content (some href, for example) to the client?
>    > RFC 2158 states that 204 (no content) is the default success code
>    > for DELETE.  I was wondering if there are special deltaV semantics.

 --=_alternative 00424B4A85256F10_=-- From w3c-dist-auth-request@w3.org Wed Sep 15 08:18: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 IAA26789 for ; Wed, 15 Sep 2004 08:18:01 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7Yj5-0004AI-MN; Wed, 15 Sep 2004 12:17:31 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C7Yj5-00048v-7J for w3c-dist-auth@listhub.w3.org; Wed, 15 Sep 2004 12:17:31 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C7Yj3-0002wR-AG for w3c-dist-auth@w3.org; Wed, 15 Sep 2004 12:17:29 +0000 Received: (qmail 31619 invoked by uid 65534); 15 Sep 2004 12:16:58 -0000 Received: from p50824B4B.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.75.75) by mail.gmx.net (mp011) with SMTP; 15 Sep 2004 14:16:58 +0200 X-Authenticated: #1915285 Message-ID: <414832B8.8010406@gmx.de> Date: Wed, 15 Sep 2004 14:16:56 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: webdav , "'ietf-dav-versioning@w3.org'" 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: succeed code for DELETE X-Archived-At: http://www.w3.org/mid/414832B8.8010406@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8844 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, 15 Sep 2004 12:17:31 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > Good catch, Girish! > > RFC-2518bis team: Please add this to the list of editorial issues > for 2518. > > These two sentences in 8.6 (in 8.7 of 2518bis) should be deleted. > The first sentence is wrong, because 204 is not an error, and so > there is no such thing as a "204 (No Content) error". > The second sentence is wrong, because 204 (No Content) is not > the "default success code". > > Cheers, > Geoff +1 > Girish wrote on 09/15/2004 02:58:50 AM: > > At the end of section 8.6 (DELETE), there is a statement which > > states that 204 should not be included in a 207. > > "Additionally 204 (No Content) errors SHOULD NOT be returned in > > the 207 (Multi-Status).The reason for this prohibition is that > > 204 (No Content) is the default success code." > > It was this particular phrase which confused me. > > > Girish wrote on 09/14/2004 10:42:32 AM: > > > Can a successful DELETE (in my case, deletion of a version-history) > > > return some content (some href, for example) to the client? > > > RFC 2158 states that 204 (no content) is the default success code > > > for DELETE. I was wondering if there are special deltaV semantics. Yet, why would you *want* to send a response body upon DELETE? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Sep 15 10:39: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 KAA09430 for ; Wed, 15 Sep 2004 10:39:50 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7awB-0005oI-Q6; Wed, 15 Sep 2004 14:39:11 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C7awA-0005mv-Ui for w3c-dist-auth@listhub.w3.org; Wed, 15 Sep 2004 14:39:10 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C7awA-00037i-K9 for w3c-dist-auth@w3.org; Wed, 15 Sep 2004 14:39:10 +0000 Received: (qmail 30601 invoked by uid 65534); 15 Sep 2004 14:38:38 -0000 Received: from p50824BAD.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.75.173) by mail.gmx.net (mp027) with SMTP; 15 Sep 2004 16:38:38 +0200 X-Authenticated: #1915285 Message-ID: <414853ED.90207@gmx.de> Date: Wed, 15 Sep 2004 16:38:37 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: www-webdav-dasl@w3.org References: <41357711.1080309@gmx.de> <41443EC2.9060808@gmx.de> In-Reply-To: <41443EC2.9060808@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: Last-calling draft-reschke-webdav-property-datatypes-07, Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/414853ED.90207@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8845 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, 15 Sep 2004 14:39:11 +0000 Content-Transfer-Encoding: 7bit OK, here's an issue I'd like to fix in the draft ([1]): the current text speaks about PROPFIND, but what it *really* should be saying that this change applies to all methods that return RFC2518-style multistatus response bodies (such as REPORT/DAV:expand-property, defined in RFC3253, or SEARCH). Proposal: add a new section (6) "Changes for other methods", specifying this (this will also add an informative reference to RFC3253 if we mention REPORT). Feedback appreciated, Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Sep 15 13:18: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 NAA21448 for ; Wed, 15 Sep 2004 13:18:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7dPp-0007ze-TU; Wed, 15 Sep 2004 17:17:57 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C7dPo-0007yo-UD; Wed, 15 Sep 2004 17:17:56 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by bart.w3.org with esmtp (Exim 4.34) id 1C7dPo-0003bb-PH; Wed, 15 Sep 2004 17:17:56 +0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8FHH1bw053184; Wed, 15 Sep 2004 13:17:01 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8FHIEGi075316; Wed, 15 Sep 2004 13:18:14 -0400 In-Reply-To: <414853ED.90207@gmx.de> To: Julian Reschke Cc: w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org, www-webdav-dasl@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, 15 Sep 2004 13:16:59 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF535 | September 3, 2004) at 09/15/2004 13:17:00, Serialize complete at 09/15/2004 13:17:00 Content-Type: multipart/alternative; boundary="=_alternative 005EF0E085256F10_=" 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: Last-calling draft-reschke-webdav-property-datatypes-07, Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/OFDE4D0756.2661EF54-ON85256F10.005EE9F7-85256F10.005EF0E7@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8846 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, 15 Sep 2004 17:17:57 +0000 This is a multipart message in MIME format. --=_alternative 005EF0E085256F10_= Content-Type: text/plain; charset="US-ASCII" That's fine with me. Cheers, Geoff Julian wrote on 09/15/2004 10:38:37 AM: > > OK, > > here's an issue I'd like to fix in the draft ([1]): > > the current text speaks about PROPFIND, but what it *really* should be > saying that this change applies to all methods that return RFC2518-style > multistatus response bodies (such as REPORT/DAV:expand-property, defined > in RFC3253, or SEARCH). > > Proposal: add a new section (6) "Changes for other methods", specifying > this (this will also add an informative reference to RFC3253 if we > mention REPORT). > > Feedback appreciated, Julian > > > [1] > datatypes-latest.html#rfc.issue.other-method-semantics> > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 005EF0E085256F10_= Content-Type: text/html; charset="US-ASCII"
That's fine with me.

Cheers,
Geoff


Julian wrote on 09/15/2004 10:38:37 AM:

>
> OK,
>
> here's an issue I'd like to fix in the draft ([1]):
>
> the current text speaks about PROPFIND, but what it *really* should be
> saying that this change applies to all methods that return RFC2518-style
> multistatus response bodies (such as REPORT/DAV:expand-property, defined
> in RFC3253, or SEARCH).
>
> Proposal: add a new section (6) "Changes for other methods", specifying
> this (this will also add an informative reference to RFC3253 if we
> mention REPORT).
>
> Feedback appreciated, Julian
>
>
> [1]
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-
> datatypes-latest.html#rfc.issue.other-method-semantics>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 005EF0E085256F10_=-- From w3c-dist-auth-request@w3.org Wed Sep 15 13:31: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 NAA22452 for ; Wed, 15 Sep 2004 13:31:30 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7dcP-00045A-8A; Wed, 15 Sep 2004 17:30:57 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C7dcO-00044O-Ig for w3c-dist-auth@listhub.w3.org; Wed, 15 Sep 2004 17:30:56 +0000 Received: from usmail.cocreate.com ([63.119.136.74]) by bart.w3.org with smtp (Exim 4.34) id 1C7dcO-0005wu-Al for w3c-dist-auth@w3c.org; Wed, 15 Sep 2004 17:30:56 +0000 Received: from u10sm001.us10.cocreate.com ([63.119.136.66]) by usmail.cocreate.com (SAVSMTP 3.1.3.37) with SMTP id M2004091511300621024 for ; Wed, 15 Sep 2004 11:30:06 -0600 Received: from cocreate.us10.cocreate.com ([10.31.18.3]) by u10sm001.us10.cocreate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SGMKF5H3; Wed, 15 Sep 2004 11:30:20 -0600 Received: from cocreate.com (jthomp2.us10.cocreate.com [10.31.21.55]) by cocreate.us10.cocreate.com (8.11.6/8.11.6) with ESMTP id i8FHUJN11321 for ; Wed, 15 Sep 2004 11:30:19 -0600 Message-ID: <41487C4C.6000903@cocreate.com> Date: Wed, 15 Sep 2004 11:30:52 -0600 From: Jeff Thompson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Webdav WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (bart.w3.org: domain of jeff_thompson@cocreate.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Clients on HP-UX X-Archived-At: http://www.w3.org/mid/41487C4C.6000903@cocreate.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8847 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, 15 Sep 2004 17:30:57 +0000 Content-Transfer-Encoding: 7bit Does anyone know of any DAV clients on HP-UX? Looking over the lists on WebDAV.org and the WG site, the only candidate I see is WebDAV Explorer (DAV Explorer). Implemented in Java it claims to work on a couple of *nixes, but does not mention HP-UX. Any other good places to get information on this? Jeff From w3c-dist-auth-request@w3.org Wed Sep 15 14:35: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 OAA27139 for ; Wed, 15 Sep 2004 14:35:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7ebs-0003ei-Oz; Wed, 15 Sep 2004 18:34:28 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C7ebs-0003e7-3c; Wed, 15 Sep 2004 18:34:28 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1C7ebr-0001lx-St; Wed, 15 Sep 2004 18:34:28 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth-request@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 i8FIY5pp007623 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Sep 2004 11:34:06 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Julian Reschke , w3c-dist-auth@w3.org, www-webdav-dasl@w3.org, w3c-dist-auth-request@w3.org From: Lisa Dusseault Date: Wed, 15 Sep 2004 11:33:57 -0700 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (bart.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Last-calling draft-reschke-webdav-property-datatypes-07, Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/CE23363A-0745-11D9-B25A-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8848 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, 15 Sep 2004 18:34:28 +0000 Content-Transfer-Encoding: 7bit I also think it's a good idea. Again, the draft could specify what the server MUST support, depending on what standards it has implemented. E.g. if the server has implemented both DeltaV and property data types, MUST it return whatever data typing information it has in REPORT responses? Lisa On Sep 15, 2004, at 10:16 AM, Geoffrey M Clemm wrote: > That's fine with me. > > Cheers, > Geoff > > > Julian wrote on 09/15/2004 10:38:37 AM: > >> >> OK, >> >> here's an issue I'd like to fix in the draft ([1]): >> >> the current text speaks about PROPFIND, but what it *really* should be >> saying that this change applies to all methods that return >> RFC2518-style > >> multistatus response bodies (such as REPORT/DAV:expand-property, >> defined > >> in RFC3253, or SEARCH). >> >> Proposal: add a new section (6) "Changes for other methods", >> specifying >> this (this will also add an informative reference to RFC3253 if we >> mention REPORT). >> >> Feedback appreciated, Julian >> >> >> [1] >> > datatypes-latest.html#rfc.issue.other-method-semantics> >> >> -- >> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >> From w3c-dist-auth-request@w3.org Wed Sep 15 14:47: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 OAA27969 for ; Wed, 15 Sep 2004 14:47:53 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7eoN-0000CE-Fd; Wed, 15 Sep 2004 18:47:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C7eoM-0000BY-Qf for w3c-dist-auth@listhub.w3.org; Wed, 15 Sep 2004 18:47:22 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1C7eoL-00014G-0S for w3c-dist-auth@w3c.org; Wed, 15 Sep 2004 18:47:21 +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 i8FIlEpp008269 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Sep 2004 11:47:17 -0700 In-Reply-To: <41487C4C.6000903@cocreate.com> References: <41487C4C.6000903@cocreate.com> 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: Wed, 15 Sep 2004 11:47:08 -0700 To: Jeff Thompson X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (lisa.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Clients on HP-UX X-Archived-At: http://www.w3.org/mid/A5A1CCB2-0747-11D9-B25A-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8849 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, 15 Sep 2004 18:47:23 +0000 Content-Transfer-Encoding: 7bit I find sitecopy very useful and it should work on most *nixes as well. I don't know for sure, maybe it would just need to be compiled on the new unix. Lisa On Sep 15, 2004, at 10:30 AM, Jeff Thompson wrote: > > Does anyone know of any DAV clients on HP-UX? > > Looking over the lists on WebDAV.org and the WG site, the only > candidate I see is WebDAV Explorer (DAV Explorer). Implemented in Java > it claims to work on a couple of *nixes, but does not mention HP-UX. > > Any other good places to get information on this? > > Jeff > > From w3c-dist-auth-request@w3.org Thu Sep 16 01:18: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 BAA26485 for ; Thu, 16 Sep 2004 01:18:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C7iD2-0000h9-RP; Wed, 15 Sep 2004 22:25:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C7iCu-0000dK-9F for w3c-dist-auth@listhub.w3.org; Wed, 15 Sep 2004 22:24:56 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C7iCs-0004na-BB for w3c-dist-auth@w3.org; Wed, 15 Sep 2004 22:24:54 +0000 Received: (qmail 3630 invoked by uid 65534); 15 Sep 2004 22:24:23 -0000 Received: from pD9FF03A2.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.3.162) by mail.gmx.net (mp017) with SMTP; 16 Sep 2004 00:24:23 +0200 X-Authenticated: #1915285 Message-ID: <4148C114.50300@gmx.de> Date: Thu, 16 Sep 2004 00:24:20 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , w3c-dist-auth@w3.org, www-webdav-dasl@w3.org, 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 (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: Last-calling draft-reschke-webdav-property-datatypes-07, Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/4148C114.50300@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8850 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, 15 Sep 2004 22:25:04 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > I also think it's a good idea. Again, the draft could specify what the > server MUST support, depending on what standards it has implemented. > E.g. if the server has implemented both DeltaV and property data types, > MUST it return whatever data typing information it has in REPORT responses? That's the plan (ie., multistatus response bodies should be handled the same way no matter whether result of PROPFIND, REPORT or SEARCH). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Sep 17 08:36: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 IAA00480 for ; Fri, 17 Sep 2004 08:36:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C8Hw5-0004fW-CU for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Sep 2004 12:33:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C8Hw4-0004f0-K4 for w3c-dist-auth@listhub.w3.org; Fri, 17 Sep 2004 12:33:56 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C8Hw2-000173-Is for w3c-dist-auth@w3.org; Fri, 17 Sep 2004 12:33:54 +0000 Received: (qmail 1440 invoked by uid 65534); 17 Sep 2004 12:33:24 -0000 Received: from p508256DC.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.86.220) by mail.gmx.net (mp026) with SMTP; 17 Sep 2004 14:33:24 +0200 X-Authenticated: #1915285 Message-ID: <414AD992.8020004@gmx.de> Date: Fri, 17 Sep 2004 14:33:22 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.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: BIND spec: Potential URI comparison issue X-Archived-At: http://www.w3.org/mid/414AD992.8020004@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8851 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 Sep 2004 12:33:57 +0000 Content-Transfer-Encoding: 7bit Hi, a recent discussion on the Atom mailing list reminded me to check how the BIND spec currently defines "sameness" of resources [1]: "If the values of DAV:resource-id returned by PROPFIND requests through two bindings are identical, the client can be assured that the two bindings are to the same resource." The (potential) issue here is although the spec says "indentical", people may believe that assumptions about specific URI equivalence rules are allowed. For instance, or the following URIs identical? "opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8" "Opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8" "opaquelocktoken:f81d4fae%2d7dec-11d0%2da765%2d00a0c91e6bf8" "opaquelocktoken:f81d4fae%2D7dec-11d0%2da765%2D00a0c91e6bf8" This is already non-trivial when only considering a single URI scheme, but it get's very hairy with multiple schemes. Proposal: clarify that "identical" means "identical character-by-character". Best regards, Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Sep 17 09:58: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 JAA05949 for ; Fri, 17 Sep 2004 09:58:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C8JDy-00022G-AR for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Sep 2004 13:56:30 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C8JDx-00021N-9Z; Fri, 17 Sep 2004 13:56:29 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.104]) by bart.w3.org with esmtp (Exim 4.34) id 1C8JDx-0006WV-5D; Fri, 17 Sep 2004 13:56:29 +0000 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8HDtTRS587426; Fri, 17 Sep 2004 09:55:29 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8HDufBa133844; Fri, 17 Sep 2004 09:56:42 -0400 In-Reply-To: <414AD992.8020004@gmx.de> To: Julian Reschke 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: Fri, 17 Sep 2004 09:55:27 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF535 | September 3, 2004) at 09/17/2004 09:55:28, Serialize complete at 09/17/2004 09:55:28 Content-Type: multipart/alternative; boundary="=_alternative 004C7D4E85256F12_=" 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: BIND spec: Potential URI comparison issue X-Archived-At: http://www.w3.org/mid/OF42886C6E.8121DBC6-ON85256F12.004BC204-85256F12.004C7D55@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8852 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 Sep 2004 13:56:30 +0000 This is a multipart message in MIME format. --=_alternative 004C7D4E85256F12_= Content-Type: text/plain; charset="US-ASCII" I agree that "identical" in this case should mean "identical character-by-character". Cheers, Geoff Julian wrote on 09/17/2004 08:33:22 AM: > > Hi, > > a recent discussion on the Atom mailing list reminded me to check how > the BIND spec currently defines "sameness" of resources [1]: > > "If the values of DAV:resource-id returned by PROPFIND requests through > two bindings are identical, the client can be assured that the two > bindings are to the same resource." > > The (potential) issue here is although the spec says "indentical", > people may believe that assumptions about specific URI equivalence rules > are allowed. For instance, or the following URIs identical? > > "opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8" > "Opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8" > "opaquelocktoken:f81d4fae%2d7dec-11d0%2da765%2d00a0c91e6bf8" > "opaquelocktoken:f81d4fae%2D7dec-11d0%2da765%2D00a0c91e6bf8" > > This is already non-trivial when only considering a single URI scheme, > but it get's very hairy with multiple schemes. > > Proposal: clarify that "identical" means "identical character-by-character". > > Best regards, Julian > > > [1] > html#determining.whether.two.bindings.are.to.the.same.resource> > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 004C7D4E85256F12_= Content-Type: text/html; charset="US-ASCII"
I agree that "identical" in this case should
mean "identical character-by-character".

Cheers,
Geoff

Julian wrote on 09/17/2004 08:33:22 AM:

>
> Hi,
>
> a recent discussion on the Atom mailing list reminded me to check how
> the BIND spec currently defines "sameness" of resources [1]:
>
> "If the values of DAV:resource-id returned by PROPFIND requests through
> two bindings are identical, the client can be assured that the two
> bindings are to the same resource."
>
> The (potential) issue here is although the spec says "indentical",
> people may believe that assumptions about specific URI equivalence rules
> are allowed. For instance, or the following URIs identical?
>
> "opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8"
> "Opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8"
> "opaquelocktoken:f81d4fae%2d7dec-11d0%2da765%2d00a0c91e6bf8"
> "opaquelocktoken:f81d4fae%2D7dec-11d0%2da765%2D00a0c91e6bf8"
>
> This is already non-trivial when only considering a single URI scheme,
> but it get's very hairy with multiple schemes.
>
> Proposal: clarify that "identical" means "identical character-by-character".
>
> Best regards, Julian
>
>
> [1]
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.
> html#determining.whether.two.bindings.are.to.the.same.resource>
>    
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 004C7D4E85256F12_=-- From w3c-dist-auth-request@w3.org Fri Sep 17 12:19: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 MAA16723 for ; Fri, 17 Sep 2004 12:19:22 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C8LQW-0007zR-Kp for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Sep 2004 16:17:36 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C8LQV-0007yx-TD for w3c-dist-auth@listhub.w3.org; Fri, 17 Sep 2004 16:17:35 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C8LQV-0006gg-If for w3c-dist-auth@w3.org; Fri, 17 Sep 2004 16:17:35 +0000 Received: (qmail 1421 invoked by uid 65534); 17 Sep 2004 16:17:03 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.18]) (217.5.201.10) by mail.gmx.net (mp001) with SMTP; 17 Sep 2004 18:17:03 +0200 X-Authenticated: #1915285 Message-ID: <414B0DFD.1080400@gmx.de> Date: Fri, 17 Sep 2004 18:17:01 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) 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: BIND spec: Potential URI comparison issue X-Archived-At: http://www.w3.org/mid/414B0DFD.1080400@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8853 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 Sep 2004 16:17:36 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > I agree that "identical" in this case should > mean "identical character-by-character". Ok, issue recorded and fix made in . Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Sep 17 13:00: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 NAA20324 for ; Fri, 17 Sep 2004 13:00:15 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C8M4t-0004PE-4t for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Sep 2004 16:59:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C8M4s-0004Nl-8k for w3c-dist-auth@listhub.w3.org; Fri, 17 Sep 2004 16:59: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 1C8M4q-00025Q-4X for w3c-dist-auth@w3.org; Fri, 17 Sep 2004 16:59:16 +0000 Received: (qmail 2107 invoked by uid 65534); 17 Sep 2004 16:58:45 -0000 Received: from p508257C8.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.87.200) by mail.gmx.net (mp012) with SMTP; 17 Sep 2004 18:58:45 +0200 X-Authenticated: #1915285 Message-ID: <414B17C3.70907@gmx.de> Date: Fri, 17 Sep 2004 18:58:43 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , w3c-dist-auth@w3.org, www-webdav-dasl@w3.org, 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 (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: Last-calling draft-reschke-webdav-property-datatypes-07, Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/414B17C3.70907@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8854 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 Sep 2004 16:59:19 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > I also think it's a good idea. Again, the draft could specify what the > server MUST support, depending on what standards it has implemented. > E.g. if the server has implemented both DeltaV and property data types, > MUST it return whatever data typing information it has in REPORT responses? OK. Issue and resolution: : "6. Changes for other methods Servers that support other methods using the DAV:multistatus response format (such as the REPORT method defined in [RFC3253], section 3.6) SHOULD apply the same extensions as defined in Section 5." Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Sep 18 15:21: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 PAA11133 for ; Sat, 18 Sep 2004 15:21:30 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C8kjV-0002oy-UO for w3c-dist-auth-dist@listhub.w3.org; Sat, 18 Sep 2004 19:18:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C8kjV-0002oU-67 for w3c-dist-auth@listhub.w3.org; Sat, 18 Sep 2004 19:18:53 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1C8kjT-0006f5-2F for w3c-dist-auth@w3.org; Sat, 18 Sep 2004 19:18:51 +0000 Received: (qmail 12079 invoked by uid 65534); 18 Sep 2004 19:18:19 -0000 Received: from p54856FD9.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.111.217) by mail.gmx.net (mp016) with SMTP; 18 Sep 2004 21:18:19 +0200 X-Authenticated: #1915285 Message-ID: <414C89DF.8080101@gmx.de> Date: Sat, 18 Sep 2004 21:17:51 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Luther CC: w3c-dist-auth@w3.org References: <58BB3662-059E-11D9-A08C-000A95DC65E0@apple.com> In-Reply-To: <58BB3662-059E-11D9-A08C-000A95DC65E0@apple.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: rfc2518bis Safe Methods vs Redirection issue X-Archived-At: http://www.w3.org/mid/414C89DF.8080101@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8855 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 Sep 2004 19:18:53 +0000 Content-Transfer-Encoding: 7bit Jim Luther wrote: > > In the HTTP/1.1 Specification Errata > there is a section titled "Safe Methods vs Redirection" which concludes > with "It would also be helpful for each of the method definition > sections to specifically define whether or not the method is safe. > OPTIONS, GET, and HEAD are all safe in RFC 2616. HTTP extensions like > WebDAV define additional safe methods." > > I don't see anywhere in rfc2518 or rfc2518bis where WebDAV methods are > defined as safe or unsafe. rfc2518bis should probably state which WebDAV > methods are safe and which are unsafe. > > In my code, I'm assuming PROPFIND is a safe method and that PROPPATCH, > MKCOL, COPY, MOVE, LOCK, and UNLOCK are unsafe methods by the > definitions in rfc2616, section 9.1.1 "Safe Methods". Does that sound > right to the working group? So should we state this in the BIND spec? Such as: BIND This method is unsafe and idempotent (see RFC2616, section 9.1). REBIND This method is unsafe and idempotent (see RFC2616, section 9.1). UNBIND This method is unsafe and idempotent (see RFC2616, section 9.1). Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Sep 18 15: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 PAA13188 for ; Sat, 18 Sep 2004 15:57:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C8lJX-00078b-6M for w3c-dist-auth-dist@listhub.w3.org; Sat, 18 Sep 2004 19:56:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C8lJW-000787-Go for w3c-dist-auth@listhub.w3.org; Sat, 18 Sep 2004 19:56:06 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C8lJU-0002DI-Cp for w3c-dist-auth@w3.org; Sat, 18 Sep 2004 19:56:04 +0000 Received: (qmail 21899 invoked by uid 65534); 18 Sep 2004 19:55:34 -0000 Received: from p54856FD9.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.111.217) by mail.gmx.net (mp002) with SMTP; 18 Sep 2004 21:55:34 +0200 X-Authenticated: #1915285 Message-ID: <414C929C.1050400@gmx.de> Date: Sat, 18 Sep 2004 21:55:08 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: Joe Hildebrand References: <8D96EDA0AC04D31197B400A0C96C14800E2C646D@corp.webb.net> <41260721.2040707@gmx.de> <413B4DEC.1030201@gmx.de> <0D1D2D6A-FFB5-11D8-BF77-000A95B2BB72@osafoundation.org> In-Reply-To: <0D1D2D6A-FFB5-11D8-BF77-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: Notes from IETF-60 WebDAV WG Meeting X-Archived-At: http://www.w3.org/mid/414C929C.1050400@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8856 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 Sep 2004 19:56:07 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > How about a fuller response after the American long weekend (after > Monday)? August is full of vacations for many. OK, another two weeks without any progress. At this point, it seems to me that we should simply last-call the document. This seems to be the best way to focus the attention of the working group on the task of actually finishing this document. Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Sep 18 22:22: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 WAA00160 for ; Sat, 18 Sep 2004 22:22:51 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C8rJt-0001CV-7B for w3c-dist-auth-dist@listhub.w3.org; Sun, 19 Sep 2004 02:20:53 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C8rJs-0001Bc-9Q; Sun, 19 Sep 2004 02:20:52 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.102]) by bart.w3.org with esmtp (Exim 4.34) id 1C8rJq-0003O2-HD; Sun, 19 Sep 2004 02:20:52 +0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8J2K67J124480; Sat, 18 Sep 2004 22:20:06 -0400 Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8J2LF49045878; Sat, 18 Sep 2004 22:21:15 -0400 In-Reply-To: <414C89DF.8080101@gmx.de> To: Julian Reschke Cc: Jim Luther , 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: Sat, 18 Sep 2004 22:19:54 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF562 | September 17, 2004) at 09/18/2004 22:20:01, Serialize complete at 09/18/2004 22:20:01 Content-Type: multipart/alternative; boundary="=_alternative 000CCF4185256F14_=" 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: rfc2518bis Safe Methods vs Redirection issue X-Archived-At: http://www.w3.org/mid/OFB14CC327.BB6190F7-ON85256F14.000CC4FE-85256F14.000CCF44@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8857 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: Sun, 19 Sep 2004 02:20:53 +0000 This is a multipart message in MIME format. --=_alternative 000CCF4185256F14_= Content-Type: text/plain; charset="US-ASCII" That would be fine with me. Cheers, Geoff Julian wrote on 09/18/2004 03:17:51 PM: > > Jim Luther wrote: > > > > In the HTTP/1.1 Specification Errata > > there is a section titled "Safe Methods vs Redirection" which concludes > > with "It would also be helpful for each of the method definition > > sections to specifically define whether or not the method is safe. > > OPTIONS, GET, and HEAD are all safe in RFC 2616. HTTP extensions like > > WebDAV define additional safe methods." > > > > I don't see anywhere in rfc2518 or rfc2518bis where WebDAV methods are > > defined as safe or unsafe. rfc2518bis should probably state which WebDAV > > methods are safe and which are unsafe. > > > > In my code, I'm assuming PROPFIND is a safe method and that PROPPATCH, > > MKCOL, COPY, MOVE, LOCK, and UNLOCK are unsafe methods by the > > definitions in rfc2616, section 9.1.1 "Safe Methods". Does that sound > > right to the working group? > > So should we state this in the BIND spec? Such as: > > BIND > > This method is unsafe and idempotent (see RFC2616, section 9.1). > > REBIND > > This method is unsafe and idempotent (see RFC2616, section 9.1). > > UNBIND > > This method is unsafe and idempotent (see RFC2616, section 9.1). > > > Feedback appreciated, > > Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 000CCF4185256F14_= Content-Type: text/html; charset="US-ASCII"
That would be fine with me.

Cheers,
Geoff

Julian wrote on 09/18/2004 03:17:51 PM:

>
> Jim Luther wrote:
> >
> > In the HTTP/1.1 Specification Errata <http://purl.org/NET/http-errata>
> > there is a section titled "Safe Methods vs Redirection" which concludes
> > with "It would also be helpful for each of the method definition
> > sections to specifically define whether or not the method is safe.
> > OPTIONS, GET, and HEAD are all safe in RFC 2616. HTTP extensions like
> > WebDAV define additional safe methods."
> >
> > I don't see anywhere in rfc2518 or rfc2518bis where WebDAV methods are
> > defined as safe or unsafe. rfc2518bis should probably state which WebDAV
> > methods are safe and which are unsafe.
> >
> > In my code, I'm assuming PROPFIND is a safe method and that PROPPATCH,
> > MKCOL, COPY, MOVE, LOCK, and UNLOCK are unsafe methods by the
> > definitions in rfc2616, section 9.1.1 "Safe Methods". Does that sound
> > right to the working group?
>
> So should we state this in the BIND spec? Such as:
>
> BIND
>
> This method is unsafe and idempotent (see RFC2616, section 9.1).
>
> REBIND
>
> This method is unsafe and idempotent (see RFC2616, section 9.1).
>
> UNBIND
>
> This method is unsafe and idempotent (see RFC2616, section 9.1).
>
>
> Feedback appreciated,
>
> Julian
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 000CCF4185256F14_=-- From w3c-dist-auth-request@w3.org Sat Sep 18 22:38: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 WAA00727 for ; Sat, 18 Sep 2004 22:38:52 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C8raW-0005Ax-MU for w3c-dist-auth-dist@listhub.w3.org; Sun, 19 Sep 2004 02:38:04 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C8raW-0005AO-3f for w3c-dist-auth@listhub.w3.org; Sun, 19 Sep 2004 02:38:04 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.103]) by bart.w3.org with esmtp (Exim 4.34) id 1C8raW-0005E4-07 for w3c-dist-auth@w3.org; Sun, 19 Sep 2004 02:38:04 +0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8J2bWRK617828 for ; Sat, 18 Sep 2004 22:37:32 -0400 Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8J2ck49056510 for ; Sat, 18 Sep 2004 22:38:46 -0400 In-Reply-To: <414C929C.1050400@gmx.de> 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: Sat, 18 Sep 2004 22:37:30 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF562 | September 17, 2004) at 09/18/2004 22:37:31, Serialize complete at 09/18/2004 22:37:31 Content-Type: multipart/alternative; boundary="=_alternative 000E6C1885256F14_=" 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: Notes from IETF-60 WebDAV WG Meeting X-Archived-At: http://www.w3.org/mid/OF9D9DE652.13366665-ON85256F14.000E0EEE-85256F14.000E6C1A@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8858 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: Sun, 19 Sep 2004 02:38:04 +0000 This is a multipart message in MIME format. --=_alternative 000E6C1885256F14_= Content-Type: text/plain; charset="US-ASCII" I believe that issuing a last call is the only mechanism that will get the attention needed to complete this document. We have had several non-last call attempts to generate this attention, and none have succeeded. Cheers, Geoff Julian wrote on 09/18/2004 03:55:08 PM: > > Lisa Dusseault wrote: > > > > How about a fuller response after the American long weekend (after > > Monday)? August is full of vacations for many. > > OK, > > another two weeks without any progress. > > At this point, it seems to me that we should simply last-call the > document. This seems to be the best way to focus the attention of the > working group on the task of actually finishing this document. > > Feedback appreciated, > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 000E6C1885256F14_= Content-Type: text/html; charset="US-ASCII"
I believe that issuing a last call is the only mechanism that will get
the attention needed to complete this document.  We have had several
non-last call attempts to generate this attention, and none have succeeded.

Cheers,
Geoff

Julian wrote on 09/18/2004 03:55:08 PM:

>
> Lisa Dusseault wrote:
> >
> > How about a fuller response after the American long weekend (after
> > Monday)?  August is full of vacations for many.
>
> OK,
>
> another two weeks without any progress.
>
> At this point, it seems to me that we should simply last-call the
> document. This seems to be the best way to focus the attention of the
> working group on the task of actually finishing this document.
>
> Feedback appreciated,
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 000E6C1885256F14_=-- From w3c-dist-auth-request@w3.org Sun Sep 19 08:05: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 IAA12250 for ; Sun, 19 Sep 2004 08:05:27 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C90PG-00008q-LU for w3c-dist-auth-dist@listhub.w3.org; Sun, 19 Sep 2004 12:03:02 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C90PF-00008B-Sy for w3c-dist-auth@listhub.w3.org; Sun, 19 Sep 2004 12:03:01 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C90PF-0001bx-IV for w3c-dist-auth@w3.org; Sun, 19 Sep 2004 12:03:01 +0000 Received: (qmail 3988 invoked by uid 65534); 19 Sep 2004 12:02:27 -0000 Received: from p54856EEC.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.110.236) by mail.gmx.net (mp021) with SMTP; 19 Sep 2004 14:02:27 +0200 X-Authenticated: #1915285 Message-ID: <414D754D.5000906@gmx.de> Date: Sun, 19 Sep 2004 14:02:21 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: Geoffrey M Clemm , Jim Luther 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: rfc2518bis Safe Methods vs Redirection issue X-Archived-At: http://www.w3.org/mid/414D754D.5000906@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8859 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: Sun, 19 Sep 2004 12:03:02 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > That would be fine with me. > > Cheers, > Geoff OK, done: . I'll make a similar change to the REDIRECT draft. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 20 13:07: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 NAA21292 for ; Mon, 20 Sep 2004 13:07:22 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C9Rai-0000cD-K9 for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Sep 2004 17:04:40 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C9Rah-0000bj-RV for w3c-dist-auth@listhub.w3.org; Mon, 20 Sep 2004 17:04:39 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1C9Raf-0003zq-Lg for w3c-dist-auth@w3.org; Mon, 20 Sep 2004 17:04:37 +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 i8KH4LBm001043 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 20 Sep 2004 10:04:22 -0700 In-Reply-To: <414C89DF.8080101@gmx.de> References: <58BB3662-059E-11D9-A08C-000A95DC65E0@apple.com> <414C89DF.8080101@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1935B2AB-0B27-11D9-BF97-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org, Jim Luther From: Lisa Dusseault Date: Mon, 20 Sep 2004 10:04:13 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (lisa.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: rfc2518bis Safe Methods vs Redirection issue X-Archived-At: http://www.w3.org/mid/1935B2AB-0B27-11D9-BF97-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8860 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, 20 Sep 2004 17:04:40 +0000 Content-Transfer-Encoding: 7bit I agree -- they all should be unsafe but idempotent. Lisa On Sep 18, 2004, at 12:17 PM, Julian Reschke wrote: > > Jim Luther wrote: >> In the HTTP/1.1 Specification Errata >> there is a section titled "Safe >> Methods vs Redirection" which concludes with "It would also be >> helpful for each of the method definition sections to specifically >> define whether or not the method is safe. OPTIONS, GET, and HEAD are >> all safe in RFC 2616. HTTP extensions like WebDAV define additional >> safe methods." >> I don't see anywhere in rfc2518 or rfc2518bis where WebDAV methods >> are defined as safe or unsafe. rfc2518bis should probably state which >> WebDAV methods are safe and which are unsafe. >> In my code, I'm assuming PROPFIND is a safe method and that >> PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK are unsafe methods by >> the definitions in rfc2616, section 9.1.1 "Safe Methods". Does that >> sound right to the working group? > > So should we state this in the BIND spec? Such as: > > BIND > > This method is unsafe and idempotent (see RFC2616, section 9.1). > > REBIND > > This method is unsafe and idempotent (see RFC2616, section 9.1). > > UNBIND > > This method is unsafe and idempotent (see RFC2616, section 9.1). > > > Feedback appreciated, > > Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Mon Sep 20 18:14: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 SAA28209 for ; Mon, 20 Sep 2004 18:14:51 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C9WOk-0006MT-FW for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Sep 2004 22:12:38 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C9WOj-0006Lb-6w; Mon, 20 Sep 2004 22:12:37 +0000 Received: from numenor.qualcomm.com ([129.46.51.58]) by bart.w3.org with esmtp (Exim 4.34) id 1C9WOi-0004gt-Uv; Mon, 20 Sep 2004 22:12:37 +0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i8KMBk1i010752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Sep 2004 15:11:46 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i8KMBhDY018916; Mon, 20 Sep 2004 15:11:44 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <414AD992.8020004@gmx.de> <414B0DFD.1080400@gmx.de> References: <414AD992.8020004@gmx.de> <414B0DFD.1080400@gmx.de> Date: Mon, 20 Sep 2004 15:11:42 -0700 To: Julian Reschke , w3c-dist-auth@w3.org, Geoffrey M Clemm From: Ted Hardie Cc: w3c-dist-auth-request@w3.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Received-SPF: none (bart.w3.org: domain of hardie@qualcomm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND spec: Potential URI comparison issue X-Archived-At: http://www.w3.org/mid/p06110409bd7503407d52@%5B129.46.227.161%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8861 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, 20 Sep 2004 22:12:38 +0000 At 2:33 PM +0200 9/17/04, Julian Reschke wrote: >Hi, > >a recent discussion on the Atom mailing list reminded me to check >how the BIND spec currently defines "sameness" of resources [1]: > >"If the values of DAV:resource-id returned by PROPFIND requests >through two bindings are identical, the client can be assured that >the two bindings are to the same resource." > >The (potential) issue here is although the spec says "indentical", >people may believe that assumptions about specific URI equivalence >rules are allowed. For instance, or the following URIs identical? > >"opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8" >"Opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8" >"opaquelocktoken:f81d4fae%2d7dec-11d0%2da765%2d00a0c91e6bf8" >"opaquelocktoken:f81d4fae%2D7dec-11d0%2da765%2D00a0c91e6bf8" > >This is already non-trivial when only considering a single URI >scheme, but it get's very hairy with multiple schemes. > >Proposal: clarify that "identical" means "identical character-by-character". > >Best regards, Julian > opaquelocktoken is defined in 2518, at least if I am reading the URI scheme registrations at IANA correctly. Are you planning to update 2518? If so, do you plan to change the generation reference from the UUID reference (ISO 11578) to something else? As it stands now, I would expect implementations to treat to tokens as equivalent if the UUID would be equivalent. Note as well that equivalence of the scheme name (Opaquelocktoken vs. opaquelocktoken) is different to the equivalence of the token. 2396bis defines the scheme as case-insensitive, even though the canonical form is lower case. regards, Ted Hardie From w3c-dist-auth-request@w3.org Mon Sep 20 19:40: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 TAA07820 for ; Mon, 20 Sep 2004 19:40:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C9Xk2-0001AP-FU for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Sep 2004 23:38:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C9Xk1-00019o-Jd for w3c-dist-auth@listhub.w3.org; Mon, 20 Sep 2004 23:38:41 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1C9Xjz-0000Ep-AZ for w3c-dist-auth@w3.org; Mon, 20 Sep 2004 23:38:39 +0000 Received: (qmail 26553 invoked by uid 65534); 20 Sep 2004 23:38:08 -0000 Received: from p50825F49.dip.t-dialin.net (EHLO [192.168.0.3]) (80.130.95.73) by mail.gmx.net (mp015) with SMTP; 21 Sep 2004 01:38:08 +0200 X-Authenticated: #1915285 Message-ID: <414F69D9.5060007@gmx.de> Date: Tue, 21 Sep 2004 01:38:01 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie CC: w3c-dist-auth@w3.org, Geoffrey M Clemm References: <414AD992.8020004@gmx.de> <414B0DFD.1080400@gmx.de> 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: BIND spec: Potential URI comparison issue X-Archived-At: http://www.w3.org/mid/414F69D9.5060007@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8862 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, 20 Sep 2004 23:38:42 +0000 Content-Transfer-Encoding: 7bit Ted Hardie wrote: > ... > opaquelocktoken is defined in 2518, at least if I am reading the URI scheme > registrations at IANA correctly. Are you planning to update 2518? If so, No. > do you plan to change the generation reference from the UUID reference > (ISO 11578) to something else? As it stands now, I would expect > implementations to treat to tokens as equivalent if the UUID would > be equivalent. Well, the BIND spec allows *any* URI scheme. We can't expect recipients of DAV:resource-id properties to be aware of special comparison rules for specific URI schemes. So the simplest way to achieve interoperability is to specify one specific comparison that can be implemented by everybody without any knowledge of the various levels of URI equivalence (see RFC2396bis). Note that this is the same problem as in XML Namespaces and in Atom, thus the same solution. > Note as well that equivalence of the scheme name (Opaquelocktoken vs. > opaquelocktoken) is different to the equivalence of the token. 2396bis > defines the scheme as case-insensitive, even though the canonical > form is lower case. Yes. That's why we want to keep this simple (if the simplest solution works, why choose a different one?). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 20 20:16: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 UAA09864 for ; Mon, 20 Sep 2004 20:16:32 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C9YJH-0002Vb-Ih for w3c-dist-auth-dist@listhub.w3.org; Tue, 21 Sep 2004 00:15:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C9YJG-0002V7-Rw for w3c-dist-auth@listhub.w3.org; Tue, 21 Sep 2004 00:15:06 +0000 Received: from numenor.qualcomm.com ([129.46.51.58]) by lisa.w3.org with esmtp (Exim 4.34) id 1C9YJE-0005SW-Kc for w3c-dist-auth@w3.org; Tue, 21 Sep 2004 00:15:04 +0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i8L0ET1i020063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Sep 2004 17:14:30 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i8L0EQWX007814; Mon, 20 Sep 2004 17:14:27 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <414F69D9.5060007@gmx.de> References: <414AD992.8020004@gmx.de> <414B0DFD.1080400@gmx.de> <414F69D9.5060007@gmx.de> Date: Mon, 20 Sep 2004 17:14:25 -0700 To: Julian Reschke From: Ted Hardie Cc: w3c-dist-auth@w3.org, Geoffrey M Clemm Content-Type: text/plain; charset="us-ascii" ; format="flowed" Received-SPF: none (lisa.w3.org: domain of hardie@qualcomm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND spec: Potential URI comparison issue X-Archived-At: http://www.w3.org/mid/p0611040ebd751f7118e4@%5B129.46.227.161%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8863 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 Sep 2004 00:15:07 +0000 At 1:38 AM +0200 9/21/04, Julian Reschke wrote: >Ted Hardie wrote: >>... >>opaquelocktoken is defined in 2518, at least if I am reading the URI scheme >>registrations at IANA correctly. Are you planning to update 2518? If so, > >No. > >>do you plan to change the generation reference from the UUID reference >>(ISO 11578) to something else? As it stands now, I would expect >>implementations to treat to tokens as equivalent if the UUID would >>be equivalent. > >Well, the BIND spec allows *any* URI scheme. We can't expect >recipients of DAV:resource-id properties to be aware of special >comparison rules for specific URI schemes. So the simplest way to >achieve interoperability is to specify one specific comparison that >can be implemented by everybody without any knowledge of the various >levels of URI equivalence (see RFC2396bis). >Note that this is the same problem as in XML Namespaces and in Atom, >thus the same solution. I'm not sure I see why this a feature. Having a single, well-specified mechanism that allows you to create identifiers that have a high probability of being unique across space and time seems like goodness for this use. Why would you want to allow *any* URI scheme here? mailto: julian.reschke+mylock@gmx.de? gopher://gopher.umd.edu/my_lock? For both the xml namespace 1.0 and 1.1 recommendations, going down that path has meant dealing with the difference between two references being identical and "resolving to the same thing". The spin-cycle on that argument could wring out the garments of every parliament ever sat. Again, what's the feature here? regards, Ted Hardie From w3c-dist-auth-request@w3.org Mon Sep 20 23:15: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 XAA20087 for ; Mon, 20 Sep 2004 23:15:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C9b4u-0005Y7-W9 for w3c-dist-auth-dist@listhub.w3.org; Tue, 21 Sep 2004 03:12:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C9b4u-0005XY-1g for w3c-dist-auth@listhub.w3.org; Tue, 21 Sep 2004 03:12:28 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.104]) by lisa.w3.org with esmtp (Exim 4.34) id 1C9b4r-0007UK-UR for w3c-dist-auth@w3.org; Tue, 21 Sep 2004 03:12:26 +0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8L3BuRS805038 for ; Mon, 20 Sep 2004 23:11:56 -0400 Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8L3DAhp068798 for ; Mon, 20 Sep 2004 23:13:10 -0400 In-Reply-To: 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: Mon, 20 Sep 2004 23:11:53 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF562 | September 17, 2004) at 09/20/2004 23:11:56, Serialize complete at 09/20/2004 23:11:56 Content-Type: multipart/alternative; boundary="=_alternative 001191BE85256F16_=" 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: BIND spec: Potential URI comparison issue X-Archived-At: http://www.w3.org/mid/OF6EC26048.95EE1D0A-ON85256F16.0011393D-85256F16.001191C4@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8864 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 Sep 2004 03:12:28 +0000 This is a multipart message in MIME format. --=_alternative 001191BE85256F16_= Content-Type: text/plain; charset="US-ASCII" The reason to allow any URI scheme is to allow a reasonable implementation on existing repositories that already have a UUID scheme built-in to that repository (and are not amenable to extension with a different UUID scheme just to satisfy the WebDAV BIND specification). Cheers, Geoff Ted wrote on 09/20/2004 08:14:25 PM: > At 1:38 AM +0200 9/21/04, Julian Reschke wrote: > >Ted Hardie wrote: > >>... > >>opaquelocktoken is defined in 2518, at least if I am reading the URI scheme > >>registrations at IANA correctly. Are you planning to update 2518? If so, > > > >No. > > > >>do you plan to change the generation reference from the UUID reference > >>(ISO 11578) to something else? As it stands now, I would expect > >>implementations to treat to tokens as equivalent if the UUID would > >>be equivalent. > > > >Well, the BIND spec allows *any* URI scheme. We can't expect > >recipients of DAV:resource-id properties to be aware of special > >comparison rules for specific URI schemes. So the simplest way to > >achieve interoperability is to specify one specific comparison that > >can be implemented by everybody without any knowledge of the various > >levels of URI equivalence (see RFC2396bis). > > >Note that this is the same problem as in XML Namespaces and in Atom, > >thus the same solution. > > I'm not sure I see why this a feature. Having a single, > well-specified mechanism > that allows you to create identifiers that have a high probability of > being unique > across space and time seems like goodness for this use. Why would > you want to allow > *any* URI scheme here? mailto: julian.reschke+mylock@gmx.de? > gopher://gopher.umd.edu/my_lock? > > For both the xml namespace 1.0 and 1.1 recommendations, going down that > path has meant dealing with the difference between two references being > identical and "resolving to the same thing". The spin-cycle on that argument > could wring out the garments of every parliament ever sat. > > Again, what's the feature here? > regards, > Ted Hardie --=_alternative 001191BE85256F16_= Content-Type: text/html; charset="US-ASCII"
The reason to allow any URI scheme is to allow a reasonable implementation
on existing repositories that already have a UUID scheme built-in
to that repository (and are not amenable to extension with a different
UUID scheme just to satisfy the WebDAV BIND specification).

Cheers,
Geoff

Ted wrote on 09/20/2004 08:14:25 PM:

> At 1:38 AM +0200 9/21/04, Julian Reschke wrote:
> >Ted Hardie wrote:
> >>...
> >>opaquelocktoken is defined in 2518, at least if I am reading the URI scheme
> >>registrations at IANA correctly.   Are you planning to update 2518?  If so,
> >
> >No.
> >
> >>do you plan to change the generation reference from the UUID reference
> >>(ISO 11578) to something else?  As it stands now, I would expect
> >>implementations to treat to tokens as equivalent if the UUID would
> >>be equivalent.
> >
> >Well, the BIND spec allows *any* URI scheme. We can't expect
> >recipients of DAV:resource-id properties to be aware of special
> >comparison rules for specific URI schemes. So the simplest way to
> >achieve interoperability is to specify one specific comparison that
> >can be implemented by everybody without any knowledge of the various
> >levels of URI equivalence (see RFC2396bis).
>
> >Note that this is the same problem as in XML Namespaces and in Atom,
> >thus the same solution.
>
> I'm not sure I see why this a feature.  Having a single,
> well-specified mechanism
> that allows you to create identifiers that have a high probability of
> being unique
> across space and time seems like goodness for this use.  Why would
> you want to allow
> *any* URI scheme here?  mailto: julian.reschke+mylock@gmx.de?
> gopher://gopher.umd.edu/my_lock?
>
> For both the xml namespace 1.0 and 1.1 recommendations, going down that
> path has meant dealing with the difference between two references being
> identical and "resolving to the same thing".  The spin-cycle on that argument
> could wring out the garments of every parliament ever sat.
>
> Again, what's the feature here?
>          regards,
>                Ted Hardie

 --=_alternative 001191BE85256F16_=-- From w3c-dist-auth-request@w3.org Tue Sep 21 03:27: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 DAA18497 for ; Tue, 21 Sep 2004 03:27:39 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C9f1Z-0002Mx-91 for w3c-dist-auth-dist@listhub.w3.org; Tue, 21 Sep 2004 07:25:17 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1C9f1Y-0002LU-BW for w3c-dist-auth@listhub.w3.org; Tue, 21 Sep 2004 07:25:16 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1C9f1Y-0006Av-22 for w3c-dist-auth@w3.org; Tue, 21 Sep 2004 07:25:16 +0000 Received: (qmail 11427 invoked by uid 65534); 21 Sep 2004 07:24:43 -0000 Received: from pD9FF0B64.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.11.100) by mail.gmx.net (mp015) with SMTP; 21 Sep 2004 09:24:43 +0200 X-Authenticated: #1915285 Message-ID: <414FD734.1000305@gmx.de> Date: Tue, 21 Sep 2004 09:24:36 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie CC: w3c-dist-auth@w3.org, Geoffrey M Clemm References: <414AD992.8020004@gmx.de> <414B0DFD.1080400@gmx.de> <414F69D9.5060007@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: BIND spec: Potential URI comparison issue X-Archived-At: http://www.w3.org/mid/414FD734.1000305@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8865 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 Sep 2004 07:25:17 +0000 Content-Transfer-Encoding: 7bit Ted Hardie wrote: > I'm not sure I see why this a feature. Having a single, well-specified > mechanism > that allows you to create identifiers that have a high probability of > being unique > across space and time seems like goodness for this use. Why would you > want to allow > *any* URI scheme here? mailto: julian.reschke+mylock@gmx.de? > gopher://gopher.umd.edu/my_lock? > > For both the xml namespace 1.0 and 1.1 recommendations, going down that > path has meant dealing with the difference between two references being > identical and "resolving to the same thing". The spin-cycle on that > argument > could wring out the garments of every parliament ever sat. I personally don't think it's a problem. It has worked well for XMLNS (in practice!) and for WebDAV lock tokens. In this specfic case, there's also the fact that many document management systems *already* assign unique identifiers, and allowing any kind of URI in many cases enables systems to just re-use the IDs they already have. Requiring a single schema would also mean that this working group needs to define which. I really don't want to open *that* can of worms. To summarize: this is an interesting discussion. In many previous cases, the result was to allow any URI and to use string comparision. Right now, Atom (lots of visibility) is using the same approach. I don't think it would be a good idea to start the same thread all over again here. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Sep 21 21:15:43 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 VAA18439 for ; Tue, 21 Sep 2004 21:15:43 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C9vhG-0006ib-Ad for w3c-dist-auth-dist@listhub.w3.org; Wed, 22 Sep 2004 01:13:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C9vhF-0006i5-JL for w3c-dist-auth@listhub.w3.org; Wed, 22 Sep 2004 01:13:25 +0000 Received: from bsl-rtr.day.com ([212.249.34.130] helo=picanmix.dev.day.com) by lisa.w3.org with esmtp (Exim 4.34) id 1C9vhC-0003W6-Q4 for w3c-dist-auth@w3.org; Wed, 22 Sep 2004 01:13:23 +0000 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id i8M1DMe27389 for ; Wed, 22 Sep 2004 03:13:22 +0200 (MEST) Received: from [10.2.8.57] ([10.2.8.57]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2004092203091000:68900 ; Wed, 22 Sep 2004 03:09:10 +0200 Mime-Version: 1.0 (Apple Message framework v619) Resent-Date: Tue, 21 Sep 2004 18:09:08 -0700 Message-Id: <015DA6F7-0C34-11D9-BE81-000393753936@gbiv.com> Cc: HTTP working group , Webdav WG Resent-To: w3c-dist-auth@w3.org From: "Roy T. Fielding" Resent-From: "Roy T. Fielding" Date: Tue, 21 Sep 2004 17:16:46 -0700 To: Mark Nottingham X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 09/22/2004 03:09:10 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 09/22/2004 03:13:21 AM, Serialize complete at 09/22/2004 03:13:21 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Received-SPF: none (lisa.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: FYI: draft-nottingham-hdrreg-http-01 X-Archived-At: http://www.w3.org/mid/015DA6F7-0C34-11D9-BE81-000393753936@gbiv.com X-Mailing-List: archive/latest/8866 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 Sep 2004 01:13:26 +0000 Content-Transfer-Encoding: 7bit > -02 is now available: > > http://www.ietf.org/internet-drafts/draft-nottingham-hdrreg-http > -02.txt > > It corrects a reference and some contact details, and adds headers from > HTML 4. Yikes, that's quite a bit of work. HTTP is getting messy. I think it would help the organization a great deal if you got rid of the useless summary at the beginning of 2.1 and 2.2, and instead used the ToC for summary. E.g., 2. Standards-track HTTP Header Fields 2.1 A-IM 2.2 Accept ... 3. Experimental HTTP Header Fields ... 4. Informational HTTP Header Fields ... 5. Historic HTTP Header Fields ... 6. IANA considerations 7. Security considerations ... And then be a little more descriptive in the use if the status field to mark ancient proposals as informational or historic. Status: Specify "standard", "experimental", "informational", "historic", "obsoleted", or some other appropriate value according to the type and status of the primary document in which it is defined. For non-IETF specifications, those formally approved by other standards bodies should be labelled as "standard"; others may be "informational" or "deprecated" depending on the reason for registration. Cheers, Roy T. Fielding Chief Scientist, Day Software From w3c-dist-auth-request@w3.org Tue Sep 21 21:49: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 VAA20363 for ; Tue, 21 Sep 2004 21:49:58 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C9wFe-0002NF-AV for w3c-dist-auth-dist@listhub.w3.org; Wed, 22 Sep 2004 01:48:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C9wFc-0002M0-OI; Wed, 22 Sep 2004 01:48:56 +0000 Received: from bsl-rtr.day.com ([212.249.34.130] helo=picanmix.dev.day.com) by lisa.w3.org with esmtp (Exim 4.34) id 1C9wFa-0000al-CA; Wed, 22 Sep 2004 01:48:54 +0000 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id i8M1moe03506; Wed, 22 Sep 2004 03:48:50 +0200 (MEST) Received: from [10.2.8.57] ([10.2.8.57]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2004092203484787:70322 ; Wed, 22 Sep 2004 03:48:47 +0200 In-Reply-To: <282BCC5A-0C34-11D9-BE81-000393753936@gbiv.com> References: <5A3056EB-0C2E-11D9-B1BD-000A95BD86C0@mnot.net> <282BCC5A-0C34-11D9-BE81-000393753936@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <8A7212E6-0C39-11D9-BE81-000393753936@gbiv.com> Cc: HTTP working group , Graham Klyne , Mark Nottingham , Webdav WG From: "Roy T. Fielding" Date: Tue, 21 Sep 2004 18:48:45 -0700 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 09/22/2004 03:48:48 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 09/22/2004 03:48:54 AM, Serialize complete at 09/22/2004 03:48:54 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Received-SPF: none (lisa.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: FYI: draft-nottingham-hdrreg-http-01 X-Archived-At: http://www.w3.org/mid/8A7212E6-0C39-11D9-BE81-000393753936@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8868 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 Sep 2004 01:48:58 +0000 Content-Transfer-Encoding: 7bit Oh, bugger, never mind -- I was looking at the wrong section of RFC 3864. Status and provisional are not orthogonal at all. Why the heck was it written that way? Oh well... My suggestion remains though -- either create separate sections for each status type (so we can see which ones are miscategorized) or don't make any subsections at all (list all header fields alphabetically regardless of status). In any case, this was obviously a lot of work to prepare, so kudos regardless. ....Roy From w3c-dist-auth-request@w3.org Tue Sep 21 22:03: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 VAA18444 for ; Tue, 21 Sep 2004 21:15:43 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1C9vhZ-0006nK-By for w3c-dist-auth-dist@listhub.w3.org; Wed, 22 Sep 2004 01:13:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1C9vhY-0006mB-6w; Wed, 22 Sep 2004 01:13:44 +0000 Received: from bsl-rtr.day.com ([212.249.34.130] helo=picanmix.dev.day.com) by lisa.w3.org with esmtp (Exim 4.34) id 1C9vhV-0003ZO-Rf; Wed, 22 Sep 2004 01:13:42 +0000 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id i8M1Dbe27574; Wed, 22 Sep 2004 03:13:37 +0200 (MEST) Received: from [10.2.8.57] ([10.2.8.57]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2004092203101571:68922 ; Wed, 22 Sep 2004 03:10:15 +0200 In-Reply-To: <5A3056EB-0C2E-11D9-B1BD-000A95BD86C0@mnot.net> References: <5A3056EB-0C2E-11D9-B1BD-000A95BD86C0@mnot.net> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <282BCC5A-0C34-11D9-BE81-000393753936@gbiv.com> Cc: HTTP working group , Graham Klyne , Webdav WG From: "Roy T. Fielding" Date: Tue, 21 Sep 2004 18:10:13 -0700 To: Mark Nottingham X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 09/22/2004 03:10:15 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 09/22/2004 03:13:38 AM, Serialize complete at 09/22/2004 03:13:38 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Received-SPF: none (lisa.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: FYI: draft-nottingham-hdrreg-http-01 X-Archived-At: http://www.w3.org/mid/282BCC5A-0C34-11D9-BE81-000393753936@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8867 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 Sep 2004 01:13:45 +0000 Content-Transfer-Encoding: 7bit > Keep in mind that these are seeds for the registries, which is AFAIK > why there are the textual summaries in addition to the ToCs. Graham > Klyne (cc:ed) wrote the software that helps me generate the listings, > and is also the mastermind behind the registry itself (now RFC3864), > so he may be able to shed additional light. > > Registry entries aren't distinguished by type of standard; remember > that non-IETF registrations (e.g., W3C) are allowed. They're only > differentiated by whether they were specified by a recognised > standards process (the permanent registry) or something more ad hoc > (the provisional repository). No, that would be quite worthless. Provisional just means they haven't been used extensively yet and may disappear from the registry if they are never used. Provisional versus Permanent is a separate, orthogonal axis from status. Historic means they shouldn't be used -- the registry simply reserves the name to avoid collisions. About 1/3 of the header fields in that list should be marked historic or informational, which are distinctly different categories from standard. Standard means it is defined by a standards track document, either within or outside the IETF, not just any document. Old hypertext specs, W3C notes, discontinued Internet drafts, and IETF Informational or Historic RFCs do not qualify as standards-track. Standards-track IETF documents (draft or RFC), W3C REC track, ISO WG items, and such should be marked as standard. My suggested reorganization was to make it easier to review the fields and identify discrepancies in the templates -- right now my eyes just go blurry. Alternatively, make the summary useful by including more of the template content (status and spec reference), not "http". IANA can generate their own summary from the templates *after* they are entered within the IANA database. ....Roy From w3c-dist-auth-request@w3.org Wed Sep 22 09:56: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 JAA07997 for ; Wed, 22 Sep 2004 09:56:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CA7Ym-00026j-AD for w3c-dist-auth-dist@listhub.w3.org; Wed, 22 Sep 2004 13:53:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CA7Yl-000263-92 for w3c-dist-auth@listhub.w3.org; Wed, 22 Sep 2004 13:53:27 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1CA7Yi-0001Au-Sh for w3c-dist-auth@w3.org; Wed, 22 Sep 2004 13:53:25 +0000 Received: (qmail 4097 invoked by uid 65534); 22 Sep 2004 13:52:52 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.18]) (217.5.201.10) by mail.gmx.net (mp001) with SMTP; 22 Sep 2004 15:52:52 +0200 X-Authenticated: #1915285 Message-ID: <415183AD.80407@gmx.de> Date: Wed, 22 Sep 2004 15:52:45 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Bernard Desruisseaux , webdav References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> In-Reply-To: <5D6773F4-069E-11D9-9C6B-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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/415183AD.80407@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8869 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 Sep 2004 13:53:28 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > ... > Only a matter of setting expectations -- what this spec does provide, > what it doesn't provide. Human-readable overview text to provide > context for how to consider this work. OK, see : The following potential datatyping related features were deliberately considered out of scope: o getting "schema" information for classes of resources (set of "required" properties, their types, display information), o definition of a set of mandatory property types, o discovery of supported property types, o extensions to PROPPATCH that would allow updates to parts of a (structured) property. >... > Depends on how readable you want the spec to be. I would consider that > information very helpful and clarifying. : Servers not aware of datatype handling either drop the "xsi:type" attribute, or persist it along with the property value. However, they will never indicate successful parsing of the data type by returning back the type in the response to PROPPATCH. Thus, clients can supply type information without having to poll for server support in advance. Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 23 08:58: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 IAA09665 for ; Thu, 23 Sep 2004 08:58:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CAT8g-0005FS-7r for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Sep 2004 12:55:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CAT8f-0005Eb-E2 for w3c-dist-auth@listhub.w3.org; Thu, 23 Sep 2004 12:55:57 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CAT8d-0000Fs-2b for w3c-dist-auth@w3.org; Thu, 23 Sep 2004 12:55:55 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [66.103.195.180] (180_195_103_66-WIFI_HOTSPOTS.eng.telusmobility.com [66.103.195.180] (may be forged)) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8NCtXBm032141 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 23 Sep 2004 05:55:35 -0700 In-Reply-To: <415183AD.80407@gmx.de> References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> <415183AD.80407@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: Bernard Desruisseaux , webdav From: Lisa Dusseault Date: Thu, 23 Sep 2004 05:55:31 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (lisa.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/D9B9EE22-0D5F-11D9-AE25-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8870 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 Sep 2004 12:55:58 +0000 Content-Transfer-Encoding: 7bit Bernard & I came up with more questions yesterday: Can there be untyped arrays? How would I show an array of XML elements? E.g. would this be valid? ... Are arrays assumed to be ordered or unordered? Would it be legal for a server to reorder array values when returning them? Lisa On Sep 22, 2004, at 6:52 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> ... >> Only a matter of setting expectations -- what this spec does provide, >> what it doesn't provide. Human-readable overview text to provide >> context for how to consider this work. > > OK, see > datatypes-latest.html#rfc.issue.1_clarify_scope>: > > The following potential datatyping related features were > deliberately > considered out of scope: > > o getting "schema" information for classes of resources (set of > "required" properties, their types, display information), > > o definition of a set of mandatory property types, > > o discovery of supported property types, > > o extensions to PROPPATCH that would allow updates to parts of a > (structured) property. > > >... >> Depends on how readable you want the spec to be. I would consider >> that information very helpful and clarifying. > > datatypes-latest.html#rfc.issue.7_discovery>: > > Servers not aware of datatype handling either drop the "xsi:type" > attribute, or persist it along with the property value. However, > they will never indicate successful parsing of the data type by > returning back the type in the response to PROPPATCH. Thus, clients > can supply type information without having to poll for server > support > in advance. > > > Feedback appreciated, > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 23 09:51: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 JAA13456 for ; Thu, 23 Sep 2004 09:51:39 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CATzQ-0008Vy-La for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Sep 2004 13:50:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CATzP-0008VE-NE for w3c-dist-auth@listhub.w3.org; Thu, 23 Sep 2004 13:50:27 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CATzN-0001M3-8E for w3c-dist-auth@w3.org; Thu, 23 Sep 2004 13:50:25 +0000 Received: (qmail 27284 invoked by uid 65534); 23 Sep 2004 13:49:54 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.18]) (217.5.201.10) by mail.gmx.net (mp015) with SMTP; 23 Sep 2004 15:49:54 +0200 X-Authenticated: #1915285 Message-ID: <4152D481.2000804@gmx.de> Date: Thu, 23 Sep 2004 15:49:53 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Bernard Desruisseaux , webdav References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> <415183AD.80407@gmx.de> 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/4152D481.2000804@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8871 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 Sep 2004 13:50:28 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Bernard & I came up with more questions yesterday: > > Can there be untyped arrays? How would I show an array of XML elements? 1) Yes. You can have whatever datatypes you want. 2) It's up to you to define a type for that (so far, we haven't needed that). > E.g. would this be valid? > > > > ... > As far as I can tell, it would be legal according to . > Are arrays assumed to be ordered or unordered? Would it be legal for a > server to reorder array values when returning them? "The representation of the value of an array is an ordered sequence of elements constituting the items of the array." Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 23 10:00: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 KAA14249 for ; Thu, 23 Sep 2004 10:00:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CAU7a-0002qm-Hy for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Sep 2004 13:58:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CAU7Z-0002q8-Lt for w3c-dist-auth@listhub.w3.org; Thu, 23 Sep 2004 13:58:53 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CAU7X-0002e9-AK for w3c-dist-auth@w3.org; Thu, 23 Sep 2004 13:58:51 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [66.103.195.180] (180_195_103_66-WIFI_HOTSPOTS.eng.telusmobility.com [66.103.195.180] (may be forged)) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8NDwKBm007006 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 23 Sep 2004 06:58:22 -0700 In-Reply-To: <4152D481.2000804@gmx.de> References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> <415183AD.80407@gmx.de> <4152D481.2000804@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9F209974-0D68-11D9-AE25-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Bernard Desruisseaux , webdav From: Lisa Dusseault Date: Thu, 23 Sep 2004 06:58:18 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (lisa.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/9F209974-0D68-11D9-AE25-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8872 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 Sep 2004 13:58:54 +0000 Content-Transfer-Encoding: 7bit Can we include an example of an array of XML elements in the draft, so that implementors are likely to do it the same way? I would also like to request some words on ordering in the draft, although I agree that the W3C Note says that ordering is significant that doesn't say everything. - Say that "servers MUST preserve ordering if the server is storing a dead property in array format" or something equivalent - What clients should do is a little less clear but let's take a stab at it: clients that are adding a new value, removing a value, or changing a value in an array SHOULD maintain the rest of the array ordering, unless the user actually intends to resort the array to a different order. thanks, Lisa On Sep 23, 2004, at 6:49 AM, Julian Reschke wrote: > Lisa Dusseault wrote: > >> Bernard & I came up with more questions yesterday: >> Can there be untyped arrays? How would I show an array of XML >> elements? > > 1) Yes. You can have whatever datatypes you want. > > 2) It's up to you to define a type for that (so far, we haven't needed > that). > >> E.g. would this be valid? >> >> >> >> ... >> > > As far as I can tell, it would be legal according to > . > >> Are arrays assumed to be ordered or unordered? Would it be legal for >> a server to reorder array values when returning them? > > "The representation of the value of an array is an ordered sequence of > elements constituting the items of the array." > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 23 10:08: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 KAA15141 for ; Thu, 23 Sep 2004 10:08:21 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CAUFy-0006Dl-Ai for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Sep 2004 14:07:34 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CAUFx-0006DH-Gb for w3c-dist-auth@listhub.w3.org; Thu, 23 Sep 2004 14:07:33 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CAUFx-0004Nl-7S for w3c-dist-auth@w3.org; Thu, 23 Sep 2004 14:07:33 +0000 Received: (qmail 6543 invoked by uid 65534); 23 Sep 2004 14:07:01 -0000 Received: from p50824E75.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.78.117) by mail.gmx.net (mp010) with SMTP; 23 Sep 2004 16:07:01 +0200 X-Authenticated: #1915285 Message-ID: <4152D883.60404@gmx.de> Date: Thu, 23 Sep 2004 16:06:59 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Bernard Desruisseaux , webdav References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> <415183AD.80407@gmx.de> <4152D481.2000804@gmx.de> <9F209974-0D68-11D9-AE25-000A95B2BB72@osafoundation.org> In-Reply-To: <9F209974-0D68-11D9-AE25-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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/4152D883.60404@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8873 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 Sep 2004 14:07:34 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Can we include an example of an array of XML elements in the draft, so > that implementors are likely to do it the same way? I'd prefer not to. Adding examples for more then the absolute trivial things (like booleans or dates) is likely to open the proverbial can of worms, because people have different tastes about types and optimal serializations. So in doubt I'd even prefer to *remove* the current appendix (as I'm not convinced that this is a good serialization format given it's based on an outdated SOAP spec; it just happens to be what we *do* implement right now). > I would also like to request some words on ordering in the draft, > although I agree that the W3C Note says that ordering is significant > that doesn't say everything. > - Say that "servers MUST preserve ordering if the server is storing a > dead property in array format" or something equivalent Again, I'd prefer not to. An array is an array; not a set. > - What clients should do is a little less clear but let's take a stab > at it: clients that are adding a new value, removing a value, or > changing a value in an array SHOULD maintain the rest of the array > ordering, unless the user actually intends to resort the array to a > different order. Well, that's the whole point of having an array. I understand that you are particulary interested in this data type because you'll need it. It seems to me that the best strategy for you is to define that type in a separate document (possibly standalone or caldav), and let the property types spec stay out of this business. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 23 10:22: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 KAA16636 for ; Thu, 23 Sep 2004 10:22:57 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CAUU1-0003PD-JI for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Sep 2004 14:22:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CAUU0-0003Oe-Ij for w3c-dist-auth@listhub.w3.org; Thu, 23 Sep 2004 14:22:04 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CAUTy-0006Nq-74 for w3c-dist-auth@w3.org; Thu, 23 Sep 2004 14:22:02 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [66.103.195.180] (180_195_103_66-WIFI_HOTSPOTS.eng.telusmobility.com [66.103.195.180] (may be forged)) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8NELbBm008746 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 23 Sep 2004 07:21:39 -0700 In-Reply-To: <4152D883.60404@gmx.de> References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> <415183AD.80407@gmx.de> <4152D481.2000804@gmx.de> <9F209974-0D68-11D9-AE25-000A95B2BB72@osafoundation.org> <4152D883.60404@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: Bernard Desruisseaux , webdav From: Lisa Dusseault Date: Thu, 23 Sep 2004 07:21:02 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Received-SPF: none (lisa.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/CC4D9B6C-0D6B-11D9-AE25-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8874 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 Sep 2004 14:22:05 +0000 Content-Transfer-Encoding: 7bit Having the data-types spec stay out of arrays would certainly simplify it, so I can't object to that approach. Certainly I would think that if somebody does an array/list/set property draft later the property data-type stuff can be re-used then. What about clarifying that XML-valued properties don't need a data type? I do disagree with the approach of minimizing examples for the reasons you cited. Isn't it a *bad* thing if people have different tastes about types and optimal serializations, and doesn't that lead to lower interoperability? Within an experimental protocol, that approach may be acceptable, but still undesirable. Lisa On Sep 23, 2004, at 7:06 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> Can we include an example of an array of XML elements in the draft, >> so that implementors are likely to do it the same way? > > I'd prefer not to. Adding examples for more then the absolute trivial > things (like booleans or dates) is likely to open the proverbial can > of worms, because people have different tastes about types and optimal > serializations. So in doubt I'd even prefer to *remove* the current > appendix (as I'm not convinced that this is a good serialization > format given it's based on an outdated SOAP spec; it just happens to > be what we *do* implement right now). > >> I would also like to request some words on ordering in the draft, >> although I agree that the W3C Note says that ordering is significant >> that doesn't say everything. >> - Say that "servers MUST preserve ordering if the server is storing >> a dead property in array format" or something equivalent > > Again, I'd prefer not to. An array is an array; not a set. > >> - What clients should do is a little less clear but let's take a >> stab at it: clients that are adding a new value, removing a value, >> or changing a value in an array SHOULD maintain the rest of the array >> ordering, unless the user actually intends to resort the array to a >> different order. > > Well, that's the whole point of having an array. > > I understand that you are particulary interested in this data type > because you'll need it. It seems to me that the best strategy for you > is to define that type in a separate document (possibly standalone or > caldav), and let the property types spec stay out of this business. > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 23 10:43: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 KAA18454 for ; Thu, 23 Sep 2004 10:43:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CAUnf-0008Pm-3p for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Sep 2004 14:42:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CAUne-0008PI-7E for w3c-dist-auth@listhub.w3.org; Thu, 23 Sep 2004 14:42:22 +0000 Received: from sophia.inria.fr ([138.96.64.20]) by lisa.w3.org with esmtp (Exim 4.34) id 1CAUnb-0000yR-PG for w3c-dist-auth@w3.org; Thu, 23 Sep 2004 14:42:20 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i8NEfZX3016403; Thu, 23 Sep 2004 16:41:35 +0200 Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i8NEfGOv016368; Thu, 23 Sep 2004 16:41:16 +0200 Received: (from ylafon@localhost) by tarantula.inria.fr (8.12.10/8.12.5) id i8NEfFSU016426; Thu, 23 Sep 2004 16:41:15 +0200 (MEST) Date: Thu, 23 Sep 2004 16:41:15 +0200 (MEST) From: Yves Lafon X-X-Sender: ylafon@tarantula.inria.fr To: Julian Reschke cc: Lisa Dusseault , Bernard Desruisseaux , webdav In-Reply-To: <4152D481.2000804@gmx.de> Message-ID: References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> <415183AD.80407@gmx.de> <4152D481.2000804@gmx.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-1095950274=:16383" Content-ID: X-Virus-Scanned: by amavisd-new at sophia.inria.fr Received-SPF: none (lisa.w3.org: domain of Yves.Lafon@sophia.inria.fr does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/Pine.GSO.4.61.0409231636320.16383@gnenaghyn.vaevn.se Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8875 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 Sep 2004 14:42:23 +0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1804928587-1095950274=:16383 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; format=flowed Content-ID: Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 23 Sep 2004, Julian Reschke wrote: > > >> E.g. would this be valid? >> >> >> >> ... >> > > As far as I can tell, it would be legal according to=20 > . > >> Are arrays assumed to be ordered or unordered? Would it be legal for a= =20 >> server to reorder array values when returning them? > > "The representation of the value of an array is an ordered sequence of=20 > elements constituting the items of the array." Btw, you should see what has been done in SOAP Version 1.2 (see http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapenc ), which= =20 is a REC and not a Note. Thanks, --=20 Yves Lafon - W3C "Baroula que barouleras, au ti=E9u toujou t'entourneras." ---559023410-1804928587-1095950274=:16383-- From w3c-dist-auth-request@w3.org Thu Sep 23 10:47: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 KAA19279 for ; Thu, 23 Sep 2004 10:47:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CAUs4-0001LP-3g for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Sep 2004 14:46:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CAUs3-0001K5-9g for w3c-dist-auth@listhub.w3.org; Thu, 23 Sep 2004 14:46:55 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CAUs0-0001XD-SB for w3c-dist-auth@w3.org; Thu, 23 Sep 2004 14:46:53 +0000 Received: (qmail 13055 invoked by uid 65534); 23 Sep 2004 14:46:23 -0000 Received: from p50824E75.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.78.117) by mail.gmx.net (mp020) with SMTP; 23 Sep 2004 16:46:23 +0200 X-Authenticated: #1915285 Message-ID: <4152E1BD.3040807@gmx.de> Date: Thu, 23 Sep 2004 16:46:21 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Bernard Desruisseaux , webdav References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> <415183AD.80407@gmx.de> <4152D481.2000804@gmx.de> <9F209974-0D68-11D9-AE25-000A95B2BB72@osafoundation.org> <4152D883.60404@gmx.de> 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/4152E1BD.3040807@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8876 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 Sep 2004 14:46:56 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Having the data-types spec stay out of arrays would certainly simplify > it, so I can't object to that approach. Certainly I would think that if > somebody does an array/list/set property draft later the property > data-type stuff can be re-used then. Yep. So is this a vote in favor of dropping Appendix A? (I would put it into a separate document, then). > What about clarifying that XML-valued properties don't need a data type? I do not agree they don't need one. As far as I concerned, the question of whether the property has just simple text content has nothing to do with whether it should have a type. For instance, it would make sense to have a common type identifier for WebDAV properties that use the popular "href*" content format. > I do disagree with the approach of minimizing examples for the reasons > you cited. Isn't it a *bad* thing if people have different tastes about > types and optimal serializations, and doesn't that lead to lower > interoperability? Within an experimental protocol, that approach may be Yes. > acceptable, but still undesirable. It's simply an area I don't want to cover here. IMHO, it makes perfect sense to state "if you have type information, this is how you can send it" without actually defining particular types (and instead, relying on existing type libraries). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 23 10:53: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 KAA19763 for ; Thu, 23 Sep 2004 10:53:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CAUxS-0002wz-GP for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Sep 2004 14:52:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CAUxR-0002wS-FB for w3c-dist-auth@listhub.w3.org; Thu, 23 Sep 2004 14:52:29 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CAUxO-0002OJ-Vm for w3c-dist-auth@w3.org; Thu, 23 Sep 2004 14:52:27 +0000 Received: (qmail 19665 invoked by uid 65534); 23 Sep 2004 14:51:56 -0000 Received: from p50824E75.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.78.117) by mail.gmx.net (mp001) with SMTP; 23 Sep 2004 16:51:56 +0200 X-Authenticated: #1915285 Message-ID: <4152E30C.5090509@gmx.de> Date: Thu, 23 Sep 2004 16:51:56 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yves Lafon CC: Lisa Dusseault , Bernard Desruisseaux , webdav References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> <415183AD.80407@gmx.de> <4152D481.2000804@gmx.de> 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/4152E30C.5090509@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8877 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 Sep 2004 14:52:30 +0000 Content-Transfer-Encoding: 7bit Yves Lafon wrote: > Btw, you should see what has been done in SOAP Version 1.2 > (see http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapenc ), > which is a REC and not a Note. > Thanks, I did a long time ago and couldn't find any description of array types anymore. Did I miss something? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 23 11:28: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 LAA22864 for ; Thu, 23 Sep 2004 11:28:42 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CAVUs-0007lV-Rm for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Sep 2004 15:27:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CAVUr-0007ku-W1 for w3c-dist-auth@listhub.w3.org; Thu, 23 Sep 2004 15:27:02 +0000 Received: from sophia.inria.fr ([138.96.64.20]) by lisa.w3.org with esmtp (Exim 4.34) id 1CAVUp-0008Jk-IF for w3c-dist-auth@w3.org; Thu, 23 Sep 2004 15:26:59 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i8NFQJX3009166; Thu, 23 Sep 2004 17:26:19 +0200 Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i8NFQAOv009105; Thu, 23 Sep 2004 17:26:10 +0200 Received: (from ylafon@localhost) by tarantula.inria.fr (8.12.10/8.12.5) id i8NFQ9Yf017212; Thu, 23 Sep 2004 17:26:09 +0200 (MEST) Date: Thu, 23 Sep 2004 17:26:09 +0200 (MEST) From: Yves Lafon X-X-Sender: ylafon@tarantula.inria.fr To: Julian Reschke cc: Lisa Dusseault , Bernard Desruisseaux , webdav In-Reply-To: <4152E30C.5090509@gmx.de> Message-ID: References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> <415183AD.80407@gmx.de> <4152D481.2000804@gmx.de> <4152E30C.5090509@gmx.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-1095953169=:17163" X-Virus-Scanned: by amavisd-new at sophia.inria.fr Received-SPF: none (lisa.w3.org: domain of Yves.Lafon@sophia.inria.fr does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/Pine.GSO.4.61.0409231723380.17163@gnenaghyn.vaevn.se Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8878 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 Sep 2004 15:27:02 +0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1804928587-1095953169=:17163 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 23 Sep 2004, Julian Reschke wrote: > Yves Lafon wrote: >> Btw, you should see what has been done in SOAP Version 1.2 >> (see http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapenc ), whi= ch=20 >> is a REC and not a Note. >> Thanks, > > I did a long time ago and couldn't find any description of array types=20 > anymore. Did I miss something? Yes, there are at http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#complexenc point 4 is about arrays, then you have http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#itemtypeattr and http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#arraySizeattr (along with a clarification in the errata http://www.w3.org/2003/06/REC-soap12-20030624-errata.html#E29 ) --=20 Yves Lafon - W3C "Baroula que barouleras, au ti=E9u toujou t'entourneras." ---559023410-1804928587-1095953169=:17163-- From w3c-dist-auth-request@w3.org Thu Sep 23 12: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 MAA27162 for ; Thu, 23 Sep 2004 12:21:30 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CAWKj-0004Fy-DF for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Sep 2004 16:20:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CAWKi-0004FP-Gr for w3c-dist-auth@listhub.w3.org; Thu, 23 Sep 2004 16:20:36 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CAWKg-0000m9-2X for w3c-dist-auth@w3.org; Thu, 23 Sep 2004 16:20:34 +0000 Received: (qmail 1673 invoked by uid 65534); 23 Sep 2004 16:20:03 -0000 Received: from p50824E75.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.78.117) by mail.gmx.net (mp001) with SMTP; 23 Sep 2004 18:20:03 +0200 X-Authenticated: #1915285 Message-ID: <4152F7B2.9020805@gmx.de> Date: Thu, 23 Sep 2004 18:20:02 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yves Lafon CC: Lisa Dusseault , Bernard Desruisseaux , webdav References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> <415183AD.80407@gmx.de> <4152D481.2000804@gmx.de> <4152E30C.5090509@gmx.de> 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: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/4152F7B2.9020805@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8879 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 Sep 2004 16:20:37 +0000 Content-Transfer-Encoding: 7bit Yves Lafon wrote: > On Thu, 23 Sep 2004, Julian Reschke wrote: > >> Yves Lafon wrote: >> >>> Btw, you should see what has been done in SOAP Version 1.2 >>> (see http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapenc ), >>> which is a REC and not a Note. >>> Thanks, >> >> >> I did a long time ago and couldn't find any description of array types >> anymore. Did I miss something? > > > Yes, there are at > http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#complexenc > point 4 is about arrays, then you have > http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#itemtypeattr > and > http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#arraySizeattr > (along with a clarification in the errata > http://www.w3.org/2003/06/REC-soap12-20030624-errata.html#E29 ) Oh, interesting. IMHO we should thus eliminate the SOAP11-based example from the spec (see ). I'm not so convinced that we should add a SOAP12 based example instead (for the simple reason that this wouldn't represent running code at Xythos and SAP anymore). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Sep 23 15:51:41 2004 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15662 for ; Thu, 23 Sep 2004 15:51:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CAZb1-0005Ds-27 for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Sep 2004 19:49:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CAZb0-0005BF-52 for w3c-dist-auth@listhub.w3.org; Thu, 23 Sep 2004 19:49:38 +0000 Received: from sophia.inria.fr ([138.96.64.20]) by lisa.w3.org with esmtp (Exim 4.34) id 1CAZax-00074n-N1 for w3c-dist-auth@w3.org; Thu, 23 Sep 2004 19:49:35 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i8NJmpX3005671; Thu, 23 Sep 2004 21:48:51 +0200 Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i8NJmVOv005568; Thu, 23 Sep 2004 21:48:32 +0200 Received: (from ylafon@localhost) by tarantula.inria.fr (8.12.10/8.12.5) id i8NJmV5g020699; Thu, 23 Sep 2004 21:48:31 +0200 (MEST) Date: Thu, 23 Sep 2004 21:48:30 +0200 (MEST) From: Yves Lafon X-X-Sender: ylafon@tarantula.inria.fr To: Julian Reschke cc: Lisa Dusseault , Bernard Desruisseaux , webdav In-Reply-To: <4152F7B2.9020805@gmx.de> Message-ID: References: <41357711.1080309@gmx.de> <41475D14.6000303@gmx.de> <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org> <415183AD.80407@gmx.de> <4152D481.2000804@gmx.de> <4152E30C.5090509@gmx.de> <4152F7B2.9020805@gmx.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-684387517-1095968910=:20554" X-Virus-Scanned: by amavisd-new at sophia.inria.fr Received-SPF: none (lisa.w3.org: domain of Yves.Lafon@sophia.inria.fr does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/Pine.GSO.4.61.0409232147011.20554@gnenaghyn.vaevn.se Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8880 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 Sep 2004 19:49:39 +0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-684387517-1095968910=:20554 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 23 Sep 2004, Julian Reschke wrote: >> Yes, there are at >> http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#complexenc >> point 4 is about arrays, then you have >> http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#itemtypeattr >> and >> http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#arraySizeattr >> (along with a clarification in the errata >> http://www.w3.org/2003/06/REC-soap12-20030624-errata.html#E29 ) > > Oh, interesting. > > IMHO we should thus eliminate the SOAP11-based example from the spec (see= =20 > ).=20 > I'm not so convinced that we should add a SOAP12 based example instead (f= or=20 > the simple reason that this wouldn't represent running code at Xythos and= SAP=20 > anymore). Agreed. Having only one example would lead to the assumption that it is=20 the only way to go, having all examples is close to impossible. --=20 Yves Lafon - W3C "Baroula que barouleras, au ti=E9u toujou t'entourneras." ---559023410-684387517-1095968910=:20554-- From w3c-dist-auth-request@w3.org Sat Sep 25 05:46: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 FAA15375 for ; Sat, 25 Sep 2004 05:46:01 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CB95F-00078b-Jq for w3c-dist-auth-dist@listhub.w3.org; Sat, 25 Sep 2004 09:43:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CB95E-000787-Mg for w3c-dist-auth@listhub.w3.org; Sat, 25 Sep 2004 09:43:12 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CB95C-0008OE-30 for w3c-dist-auth@w3.org; Sat, 25 Sep 2004 09:43:10 +0000 Received: (qmail 10287 invoked by uid 65534); 25 Sep 2004 09:42:39 -0000 Received: from pD9535DB7.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.93.183) by mail.gmx.net (mp023) with SMTP; 25 Sep 2004 11:42:39 +0200 X-Authenticated: #1915285 Message-ID: <41553D8C.40304@gmx.de> Date: Sat, 25 Sep 2004 11:42:36 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: Geoffrey M Clemm , jhildebrand@jabber.com, Lisa Dusseault , Jason Crawford , "'Jim Whitehead'" 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: Notes from IETF-60 WebDAV WG Meeting X-Archived-At: http://www.w3.org/mid/41553D8C.40304@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8881 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, 25 Sep 2004 09:43:13 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > I believe that issuing a last call is the only mechanism that will get > the attention needed to complete this document. We have had several > non-last call attempts to generate this attention, and none have succeeded. > > Cheers, > Geoff Agreed. So, Lisa and Joe, please either last-call the document, or give a clear indication about what you expect the authors to do so that we can achieve that milestone (the just revised charter at says this should have been done almost half a year ago). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Sep 25 05:49: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 FAA15465 for ; Sat, 25 Sep 2004 05:49:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CB9Ar-0008Ge-U8 for w3c-dist-auth-dist@listhub.w3.org; Sat, 25 Sep 2004 09:49:01 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CB9Ar-0008Ff-Fk for w3c-dist-auth@listhub.w3.org; Sat, 25 Sep 2004 09:49:01 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CB9Ar-0002Yl-3m for w3c-dist-auth@w3.org; Sat, 25 Sep 2004 09:49:01 +0000 Received: (qmail 23780 invoked by uid 65534); 25 Sep 2004 09:48:28 -0000 Received: from pD9535DB7.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.93.183) by mail.gmx.net (mp015) with SMTP; 25 Sep 2004 11:48:28 +0200 X-Authenticated: #1915285 Message-ID: <41553EEA.70603@gmx.de> Date: Sat, 25 Sep 2004 11:48:26 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: w3c-dist-auth@w3.org, www-webdav-dasl@w3.org References: <41357711.1080309@gmx.de> <41443EC2.9060808@gmx.de> In-Reply-To: <41443EC2.9060808@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: Last-calling draft-reschke-webdav-property-datatypes-07, Re: Request for feedback: WebDAV property datatype draft X-Archived-At: http://www.w3.org/mid/41553EEA.70603@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8882 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, 25 Sep 2004 09:49:01 +0000 Content-Transfer-Encoding: 7bit OK, thanks for the feedback that was sent within the last two weeks. I think I have captured all major issues and resolved them, either by removing questionable stuff (such as the array example using SOAP 1.1 marshalling) or adding clarifications. The current edits are published at . I plan to submit this as a new Internet Draft early next week and then ask the RFC Editor for publication as "Experimental" RFC. Note that if it gets accepted, there will be another last-call period during which issues can be raised. Best regards, Julian From w3c-dist-auth-request@w3.org Mon Sep 27 04:02: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 EAA10251 for ; Mon, 27 Sep 2004 04:02:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CBqPp-0007Xa-Iv for w3c-dist-auth-dist@listhub.w3.org; Mon, 27 Sep 2004 07:59:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CBqPo-0007X6-PL for w3c-dist-auth@listhub.w3.org; Mon, 27 Sep 2004 07:59:20 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1CBqPm-0001ih-1R for w3c-dist-auth@w3.org; Mon, 27 Sep 2004 07:59:18 +0000 Received: (qmail 26999 invoked by uid 65534); 27 Sep 2004 07:58:47 -0000 Received: from p548560D2.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.96.210) by mail.gmx.net (mp013) with SMTP; 27 Sep 2004 09:58:47 +0200 X-Authenticated: #1915285 Message-ID: <4157C832.3020401@gmx.de> Date: Mon, 27 Sep 2004 09:58:42 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.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: BIND: unused reference to RFC2026 X-Archived-At: http://www.w3.org/mid/4157C832.3020401@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8883 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 Sep 2004 07:59:21 +0000 Content-Transfer-Encoding: 7bit Hi, I just noted that the BIND draft () has an unused (normative) reference to RFC2026, which I'll remove. Unless anybody is aware of other issues, I'll submit that version for publication as draft 07 soon. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Sep 27 16:47: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 QAA03455 for ; Mon, 27 Sep 2004 16:47:13 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CC2LV-0004oX-NN for w3c-dist-auth-dist@listhub.w3.org; Mon, 27 Sep 2004 20:43:41 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CC2LU-0004mV-B8 for w3c-dist-auth@listhub.w3.org; Mon, 27 Sep 2004 20:43:40 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CC2LU-0007ii-1R for w3c-dist-auth@w3.org; Mon, 27 Sep 2004 20:43:40 +0000 Received: (qmail 22697 invoked by uid 65534); 27 Sep 2004 20:43:07 -0000 Received: from p548560D2.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.96.210) by mail.gmx.net (mp024) with SMTP; 27 Sep 2004 22:43:07 +0200 X-Authenticated: #1915285 Message-ID: <41587B51.6040709@gmx.de> Date: Mon, 27 Sep 2004 22:42:57 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: www-webdav-dasl@w3.org Content-Type: multipart/mixed; boundary="------------020200060406020906070301" 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: [Fwd: I-D ACTION:draft-reschke-webdav-property-datatypes-08.txt] X-Archived-At: http://www.w3.org/mid/41587B51.6040709@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8884 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 Sep 2004 20:43:41 +0000 This is a multi-part message in MIME format. --------------020200060406020906070301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, the new property data type draft has been published as version 08 (see announcement below). It contains the changes discussed here on this mailing list during the previous two weeks. An HTML version with change information is also available from . Edits, if required, continue on . As discussed earlier, I'll submit this draft for publication as "Experimental" RFC later soon (if it get's accepted by the RFC Editor, there'll be another IESG last-call, so any potential issues can be still be resolved). Best regards and thanks for the constructive feedback, Julian -------- Original Message -------- From: - Mon Sep 27 22:31:49 2004 X-Account-Key: account5 X-UIDL: eb9dc46c9b9e619e1f9c19b61ede2789 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 Return-Path: X-Flags: 0000 Delivered-To: GMX delivery to julian.reschke@gmx.de Received: (qmail 14085 invoked by uid 65534); 27 Sep 2004 20:30:51 -0000 Received: from megatron.ietf.org (EHLO megatron.ietf.org) (132.151.6.71) by mx0.gmx.net (mx059) with SMTP; 27 Sep 2004 22:30:51 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1li-0007AL-5T; Mon, 27 Sep 2004 16:06:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1hp-00051W-MS for i-d-announce@megatron.ietf.org; Mon, 27 Sep 2004 16:02:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26964 for ; Mon, 27 Sep 2004 16:02:39 -0400 (EDT) Message-Id: <200409272002.QAA26964@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 27 Sep 2004 16:02:39 -0400 Subject: I-D ACTION:draft-reschke-webdav-property-datatypes-08.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Datatypes for WebDAV properties Author(s) : J. Reschke Filename : draft-reschke-webdav-property-datatypes-08.txt Pages : 16 Date : 2004-9-27 This specification extends the Web Distributed Authoring Protocol (WebDAV) to support datatyping. Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reschke-webdav-property-datatypes-08.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-reschke-webdav-property-datatypes-08.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-reschke-webdav-property-datatypes-08.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. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 --------------020200060406020906070301 Content-Type: Message/External-body; name="draft-reschke-webdav-property-datatypes-08.txt" Content-Disposition: inline; filename="draft-reschke-webdav-property-datatypes-08.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-9-27151429.I-D@ietf.org> --------------020200060406020906070301 Content-Type: text/plain; name="file:///C|/DOKUME%7E1/JR/LOKALE%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOKUME%7E1/JR/LOKALE%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------020200060406020906070301-- From w3c-dist-auth-request@w3.org Wed Sep 29 09:31: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 JAA02398 for ; Wed, 29 Sep 2004 09:31:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CCeVg-0000ZC-1l for w3c-dist-auth-dist@listhub.w3.org; Wed, 29 Sep 2004 13:28:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CCeVe-0000Yi-GJ for w3c-dist-auth@listhub.w3.org; Wed, 29 Sep 2004 13:28:42 +0000 Received: from bsl-rtr.day.com ([212.249.34.130] helo=picanmix.dev.day.com) by lisa.w3.org with esmtp (Exim 4.34) id 1CCeVa-0004Ky-Hl for w3c-dist-auth@w3c.org; Wed, 29 Sep 2004 13:28:39 +0000 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id i8S7V8U28481; Tue, 28 Sep 2004 09:31:09 +0200 (MEST) Received: from [10.0.0.94] ([10.0.0.94]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2004092809310186:222347 ; Tue, 28 Sep 2004 09:31:01 +0200 In-Reply-To: <5.1.0.14.2.20040922055934.02748528@127.0.0.1> References: <5A3056EB-0C2E-11D9-B1BD-000A95BD86C0@mnot.net> <5A3056EB-0C2E-11D9-B1BD-000A95BD86C0@mnot.net> <5.1.0.14.2.20040922055934.02748528@127.0.0.1> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <52ED49D7-111E-11D9-92CC-000393753936@gbiv.com> Cc: HTTP working group , Mark Nottingham , Webdav WG From: "Roy T. Fielding" Date: Tue, 28 Sep 2004 00:16:32 -0700 To: Graham Klyne X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 09/28/2004 09:31:01 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 09/28/2004 09:33:15 AM, Serialize complete at 09/28/2004 09:33:15 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Received-SPF: none (lisa.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: FYI: draft-nottingham-hdrreg-http-01 X-Archived-At: http://www.w3.org/mid/52ED49D7-111E-11D9-92CC-000393753936@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8885 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, 29 Sep 2004 13:28:44 +0000 Content-Transfer-Encoding: 7bit > I don't entirely understand your concern here, so it's difficult to > respond in detail. It seems you're finding it harder than it should > be to review the status categorization for each header field, or is > there more? No, that's it. > At the end of the day, the specific document format is quite mutable > -- the raw data is all in RDF/N3, and I can change the software's > output moderately easily, within limits. My original plan was that > the summary consists of name + 1-line summary, because that's what > seemed useful to me. The current format results from some feedback, > and I'm open to constructive suggestions if the present format is > problematic. I just want something that is both reviewable and the same content as what you are going to give IANA. My guess is that would be simply a summary table followed by RDF, or just list the headers in separate sections by status and let the ToC be the summary. If IANA wants the templates (yuck), then just including a link to the RDF/N3 may be sufficient. >> Oh, bugger, never mind -- I was looking at the wrong section >> of RFC 3864. Status and provisional are not orthogonal at all. >> Why the heck was it written that way? Oh well... > > Well, your first take looked closer. From the PoV of the > registration, they are largely orthogonal, except that the status has > some bearing on which sub-registry is applicable. > > As for why it was written that way... it's a couple of years ago now > that this was being reviewed and debated, so the details are now > fuzzy, but I do remember there were a number of conflicting concerns > to be navigated. It reflected the balance of consensus at the time. I meant that, if "provisional" is a status, then there is no need for separate templates -- there is just one template with different values for status. That's what tripped me. I don't have any problem with provisional as a status as long as historic/deprecated drafts are not considered provisional. Note that there can only be one registry anyways, since provisional names are not allowed to collide with other names. Anyway, consider that feedback for the next time the RFC is updated. Right now I just want a way to view the intended registry content without going blind. Otherwise, there isn't much sense in sending the draft out for public review. ....Roy From w3c-dist-auth-request@w3.org Wed Sep 29 10:05: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 KAA05764 for ; Wed, 29 Sep 2004 10:05:27 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CCf4M-0002fV-EM for w3c-dist-auth-dist@listhub.w3.org; Wed, 29 Sep 2004 14:04:34 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CCf4L-0002ew-J5 for w3c-dist-auth@listhub.w3.org; Wed, 29 Sep 2004 14:04:33 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by bart.w3.org with esmtp (Exim 4.34) id 1CCf4L-000344-Cw for w3c-dist-auth@w3c.org; Wed, 29 Sep 2004 14:04:33 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 3A26B28AB20 for ; Fri, 24 Sep 2004 18:47:55 +0200 (CEST) Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id E9B5F28AB31 for ; Fri, 24 Sep 2004 18:47:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <78818126-0E49-11D9-B630-000D93C1A604@opengroupware.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'Webdav WG'" From: Helge Hess Date: Fri, 24 Sep 2004 18:47:50 +0200 X-Mailer: Apple Mail (2.619) Received-SPF: none (bart.w3.org: domain of helge.hess@opengroupware.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: D:href as a property? X-Archived-At: http://www.w3.org/mid/78818126-0E49-11D9-B630-000D93C1A604@opengroupware.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8886 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, 29 Sep 2004 14:04:34 +0000 Content-Transfer-Encoding: 7bit Hi, is it allowed to use as a regular WebDAV property? ---snip--- http://abc:8050/zidestore/so/x/IPM/Enterprises/34390 HTTP/1.1 200 OK http://abc:8050/zidestore/so/x/IPM/Enterprises/34390 ---snap--- I would assume yes. The D:href is part of the WebDAV protocol header while the contained D:href is a property being transported by WebDAV. Two relevant snippets from the spec: ---snip(section 4.5)--- Finally, it is not possible to define the same property twice on a single resource, as this would cause a collision in the resource's property namespace. ---snap--- I guess this one is pretty clear, the response/href element is not a property and therefore doesn't clash with the prop/href XML element. The thing I miss in the spec is a statement that only direct children are considered properties in a payload. This one is a bit harder: ---snip(section 12.9.1)--- A particular href MUST NOT appear more than once as the child of a response XML element ---snap--- I suppose the intention was to forbid multiple href elements directly below . But the text isn't clear whether MOST NOT applies to direct children or to deep children as well. The latter would include children of and therefore forbid D:href being exposed as a regular property. It would be great if someone could put some light on this. best regards, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From w3c-dist-auth-request@w3.org Wed Sep 29 10:14: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 KAA06763 for ; Wed, 29 Sep 2004 10:14:22 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CCfD8-0004lI-3l for w3c-dist-auth-dist@listhub.w3.org; Wed, 29 Sep 2004 14:13:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CCfD7-0004ko-OM for w3c-dist-auth@listhub.w3.org; Wed, 29 Sep 2004 14:13:37 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CCfD4-000448-SB for w3c-dist-auth@w3c.org; Wed, 29 Sep 2004 14:13:35 +0000 Received: (qmail 18824 invoked by uid 65534); 29 Sep 2004 14:13:03 -0000 Received: from p508246DF.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.70.223) by mail.gmx.net (mp006) with SMTP; 29 Sep 2004 16:13:03 +0200 X-Authenticated: #1915285 Message-ID: <415AC2EA.6080406@gmx.de> Date: Wed, 29 Sep 2004 16:12:58 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess CC: "'Webdav WG'" References: <78818126-0E49-11D9-B630-000D93C1A604@opengroupware.org> In-Reply-To: <78818126-0E49-11D9-B630-000D93C1A604@opengroupware.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: D:href as a property? X-Archived-At: http://www.w3.org/mid/415AC2EA.6080406@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8887 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, 29 Sep 2004 14:13:38 +0000 Content-Transfer-Encoding: 7bit Helge Hess wrote: > Hi, > > is it allowed to use as a regular WebDAV property? No (not until it becomes a standard WebDAV property, that is). > ---snip--- > > http://abc:8050/zidestore/so/x/IPM/Enterprises/34390 > > HTTP/1.1 200 OK > > http://abc:8050/zidestore/so/x/IPM/Enterprises/34390 > ---snap--- > > I would assume yes. The D:href is part of the WebDAV protocol header > while the contained D:href is a property being transported by WebDAV. It could be, but as no standards-track spec defines it, and it resides in the DAV: namespace, it's invalid. Anyway: I've seen servers implementing this because the Microsoft Webfolder client indeed asks for it. But, surprise, it doesn't use it. > Two relevant snippets from the spec: > > ---snip(section 4.5)--- > Finally, it is not possible to define the same property twice on a > single resource, as this would cause a collision in the resource's > property namespace. > ---snap--- > I guess this one is pretty clear, the response/href element is not a > property and therefore doesn't clash with the prop/href XML element. > The thing I miss in the spec is a statement that only direct > children are considered properties in a payload. Why would that need to be stated? > This one is a bit harder: > ---snip(section 12.9.1)--- > A particular href MUST NOT appear more than once as the child of a > response XML element > ---snap--- > I suppose the intention was to forbid multiple href elements directly > below . But the text isn't clear whether MOST NOT applies to > direct children or to deep children as well. The latter would include > children of and therefore forbid D:href being exposed as a > regular property. It applies to children in the sense of XML, thus direct children. So this restricts the multistatus response body not to have multiple response elements for the same href. It doesn't say anything at all about DAV:href elements that appear somewhere else (such as inside DAV:lockinfo). > It would be great if someone could put some light on this. Hope this helps, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Sep 29 10:26: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 KAA08730 for ; Wed, 29 Sep 2004 10:26:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CCfP3-0000eL-Id for w3c-dist-auth-dist@listhub.w3.org; Wed, 29 Sep 2004 14:25:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CCfP3-0000de-2m for w3c-dist-auth@listhub.w3.org; Wed, 29 Sep 2004 14:25:57 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by lisa.w3.org with esmtp (Exim 4.34) id 1CCfP0-0007BY-AZ for w3c-dist-auth@w3c.org; Wed, 29 Sep 2004 14:25:54 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id CFEE8291C9D for ; Wed, 29 Sep 2004 16:25:16 +0200 (CEST) Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 8CF1E291C9C for ; Wed, 29 Sep 2004 16:25:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <415AC2EA.6080406@gmx.de> References: <78818126-0E49-11D9-B630-000D93C1A604@opengroupware.org> <415AC2EA.6080406@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <67A2895A-1223-11D9-8923-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Date: Wed, 29 Sep 2004 16:25:25 +0200 To: "'Webdav WG'" X-Mailer: Apple Mail (2.619) Received-SPF: none (lisa.w3.org: domain of helge.hess@opengroupware.org does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: D:href as a property? X-Archived-At: http://www.w3.org/mid/67A2895A-1223-11D9-8923-000D93C1A604@opengroupware.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8888 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, 29 Sep 2004 14:25:57 +0000 Content-Transfer-Encoding: 7bit On Sep 29, 2004, at 16:12, Julian Reschke wrote: > It could be, but as no standards-track spec defines it, and it resides > in the DAV: namespace, it's invalid. Just out of interest: Is it stated somewhere in the spec that DAV: namespace'd properties are considered private? (again, of course this makes sense, but was not aware of this strict limitation) >> I guess this one is pretty clear, the response/href element is not a >> property and therefore doesn't clash with the prop/href XML element. >> The thing I miss in the spec is a statement that only direct >> children are considered properties in a payload. > Why would that need to be stated? Because there doesn't seem to be an explicit explanation what a "property" wrt to the spec is. I had several discussions with developers which would suggest that "D:href" as used outside the element is also a "property" and I didn't find a proof or exact specification in the standard to answer that. While it is somewhat obvious for me, it doesn't seem to be so for others. > Hope this helps, Yes, thanks a lot! Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From w3c-dist-auth-request@w3.org Wed Sep 29 12:49: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 MAA18472 for ; Wed, 29 Sep 2004 12:49:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CChcU-000417-Im for w3c-dist-auth-dist@listhub.w3.org; Wed, 29 Sep 2004 16:47:58 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CChcT-00040d-MQ for w3c-dist-auth@listhub.w3.org; Wed, 29 Sep 2004 16:47:57 +0000 Received: from adsl-67-119-69-242.dsl.sntc01.pacbell.net ([67.119.69.242] helo=mail.mnot.net) by bart.w3.org with esmtp (Exim 4.34) id 1CChcT-0005kB-FC for w3c-dist-auth@w3c.org; Wed, 29 Sep 2004 16:47:57 +0000 Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 755ED727D; Wed, 29 Sep 2004 09:47:54 -0700 (PDT) In-Reply-To: <52ED49D7-111E-11D9-92CC-000393753936@gbiv.com> References: <5A3056EB-0C2E-11D9-B1BD-000A95BD86C0@mnot.net> <5A3056EB-0C2E-11D9-B1BD-000A95BD86C0@mnot.net> <5.1.0.14.2.20040922055934.02748528@127.0.0.1> <52ED49D7-111E-11D9-92CC-000393753936@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4E913FA7-1237-11D9-88DC-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: HTTP working group , Graham Klyne , Webdav WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Date: Wed, 29 Sep 2004 09:47:53 -0700 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619) Received-SPF: none (bart.w3.org: domain of mnot@mnot.net does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: FYI: draft-nottingham-hdrreg-http-01 X-Archived-At: http://www.w3.org/mid/4E913FA7-1237-11D9-88DC-000A95BD86C0@mnot.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8889 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, 29 Sep 2004 16:47:58 +0000 Content-Transfer-Encoding: 7bit Roy, I've made the raw n3 that was used to generate the -02 draft available at: http://www.mnot.net/drafts/draft-nottingham-hdrreg-http/http_headers.n3 if that will help. Note that this wasn't intended for public consumption, so some of the prefixes aren't very well-chosen, etc. Cheers, On Sep 28, 2004, at 12:16 AM, Roy T. Fielding wrote: > If IANA wants the > templates (yuck), then just including a link to the RDF/N3 may be > sufficient. -- Mark Nottingham http://www.mnot.net/ From w3c-dist-auth-request@w3.org Wed Sep 29 15:32: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 PAA02444 for ; Wed, 29 Sep 2004 15:32:21 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CCk9m-0005S3-B5 for w3c-dist-auth-dist@listhub.w3.org; Wed, 29 Sep 2004 19:30:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CCk9l-0005RZ-JD for w3c-dist-auth@listhub.w3.org; Wed, 29 Sep 2004 19:30:29 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by lisa.w3.org with esmtp (Exim 4.34) id 1CCk9i-0007PK-R7 for w3c-dist-auth@w3.org; Wed, 29 Sep 2004 19:30:26 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02253; Wed, 29 Sep 2004 15:30:26 -0400 (EDT) Message-Id: <200409291930.PAA02253@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: Wed, 29 Sep 2004 15:30:26 -0400 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-07.txt X-Archived-At: http://www.w3.org/mid/200409291930.PAA02253@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8890 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, 29 Sep 2004 19:30: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, J. Crawford Filename : draft-ietf-webdav-bind-07.txt Pages : 34 Date : 2004-9-29 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-07.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-07.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-07.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-9-29153604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-bind-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-bind-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-29153604.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Thu Sep 30 02: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 CAA17207 for ; Thu, 30 Sep 2004 02:59:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CCut7-0007mX-Ve for w3c-dist-auth-dist@listhub.w3.org; Thu, 30 Sep 2004 06:58:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CCut7-0007lS-2d for w3c-dist-auth@listhub.w3.org; Thu, 30 Sep 2004 06:58:01 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CCut4-0006l8-51 for w3c-dist-auth@w3.org; Thu, 30 Sep 2004 06:57:58 +0000 Received: (qmail 5961 invoked by uid 65534); 30 Sep 2004 06:57:25 -0000 Received: from p50825D07.dip.t-dialin.net (EHLO [192.168.0.2]) (80.130.93.7) by mail.gmx.net (mp009) with SMTP; 30 Sep 2004 08:57:25 +0200 X-Authenticated: #1915285 Message-ID: <415BAE53.6070306@gmx.de> Date: Thu, 30 Sep 2004 08:57:23 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200409291930.PAA02253@ietf.org> In-Reply-To: <200409291930.PAA02253@ietf.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: I-D ACTION:draft-ietf-webdav-bind-07.txt X-Archived-At: http://www.w3.org/mid/415BAE53.6070306@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8891 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, 30 Sep 2004 06:58:01 +0000 Content-Transfer-Encoding: 7bit OK, this new draft contains the changes made in the two previous weeks: 'A.5 Since draft-ietf-webdav-bind-06 Rewrite Editorial Note. Open and resolve issues "2.6_identical", "specify_safeness_and_idempotence" and "ED_rfc2026_ref".' As far as I am concerned (I know I'm speaking for the currently active authors), this spec can be considered finished. There won't be any progress anymore unless more people actually sit down and read it; and the best way to achieve this is to actually issue the working group last-call (as planned in the working group's charter for May). Lisa, Joe? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760