[Fwd: Re: [Fwd: Gen-art last call review of draft-ietf-webdav-rfc2518bis-17.txt]]

(fyi)

-------- Original-Nachricht --------
From: - Mon Feb 05 05:29:34 2007
X-Account-Key: account5
X-UIDL: 9b0f68330c1a23240c36739337a290de
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path: <elwynd@dial.pipex.com>
X-Flags: 1001
Delivered-To: GMX delivery to julian.reschke@gmx.de
Received: (qmail invoked by alias); 04 Feb 2007 11:31:45 -0000
Received: from smtp.aaisp.net.uk (EHLO smtp.aaisp.net.uk) [81.187.81.51] 
  by mx0.gmx.net (mx089) with SMTP; 04 Feb 2007 12:31:45 +0100
Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] 
helo=[127.0.0.1])	by smtp.aaisp.net.uk with esmtps 
(TLSv1:AES256-SHA:256)	(Exim 4.62)	(envelope-from 
<elwynd@dial.pipex.com>)	id 1HDfaw-0006l8-G4; Sun, 04 Feb 2007 11:31:42 
+0000
Message-ID: <45C5C44D.3000601@dial.pipex.com>
Date: Sun, 04 Feb 2007 11:32:29 +0000
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
CC: WebDAV <w3c-dist-auth@w3.org>,  gen-art@ietf.org
Subject: Re: [Fwd: Gen-art last call review of 
draft-ietf-webdav-rfc2518bis-17.txt]
References: <45BF4703.2010906@gmx.de> <45C5ACEC.4050304@gmx.de>
In-Reply-To: <45C5ACEC.4050304@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-GMX-Antivirus: -1 (not scanned, may not use virus scanner)
X-GMX-Antispam: 0 (Mail was not recognized as spam)
X-GMX-UID: aYKjLzc9aHI/R+9rOyUl609qamdhZERL

Hi.

No problems with most of this.  Deleted the stuff with agreed actions.

A couple of responses in line to clarify my points...

/Elwyn

Julian Reschke wrote:
>
>> s21 IANA Considerations:
>> The various items here do not require  new registrations as they were
>> all registered as a result of RFC 2518 (and RFC 4229). This document
>
> We've been told that we should update the registrations. See
> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=86>).
Right.  Just make it clear they are updates rather than original
definitions - I think I said this rather better in the summary.
>
>> updates the registrations (and in a sense formalizes them since RFC 2518
>> did not have an IANA Considerations section explicitly). s21.1 should
>> refer to RFC 4395 which controls the URI Scheme registry. s21.3 should
>> refer to RFC 4229 which formalized the initial state of the message
>> header field registrations.  It occurs to me that I did not check if
>> there are any message headers which were in RFC 2518 but are now dropped
>> - if so this should probably be recorded here.
>
> Adding the two references is simple (opened: 
> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=264>).
>
> There indeed are headers that have been removed. However, they stay
> defined by RFC2518, so shouldn't they stay in the registry?
Yes. They will stay in the registry but given that 2518 doesn't
explicitly define the registry entries, it would probably be worth
noting the ones that are not updated (and saying this is the case) as
well as thoses that are.
>
>> s6.1, item 4: This is the first appearance of the 'depth' concept and it
>> isn't defined previously.  I think something could be usefully added to
>> the terminology section to introduce depth, and specially infinite 
>> depth.
>
> You mean to Section 1? That may be non-trivial, because it requires 
> the collection definition.
No. I meant in Section 3.  It fits conveniently just after the
Collection definition :-)
>
>> s7.4, para 2: s/a write lock/any write lock/ (I was not sure initially
>> if we were still talking about infinite-depth locks).
>
> That would result in:
>
> "Expressed otherwise, any write lock protects any request that would 
> create a new resource in a write locked collection, any request that 
> would remove an internal member URL of a write locked collection, and 
> any request that would change the segment name of any internal member."
>
> I'm not sure this is better (because of the repetition of "any").
True.  How about 'Expressed otherwise, a write lock of either kind
protects any request...'?
>
>> s8.6.2, para 2: For the less well-informed, it would be useful to
>> explain the difference between weak and string Etags at the start of
>> this discussion(or at least give an immediate reference).  As is clear
>>>> from the later words, finding a definition elsewhere is not simple!
>
> I don't think we want to define it, so the proper fix IMHO is to add a 
> proper ref [RFC2616], Section 13.3.3).
Fine by me.
>
>
> Also I note that the next paragraph claims:
>
> "Note that the meaning of an ETag in a PUT response is not clearly 
> defined either in this document or in RFC2616 (i.e., whether the ETag 
> means that the resource is octet-for-octet equivalent to the body of 
> the PUT request, or whether the server could have made minor changes 
> in the formatting or content of the document upon storage). This is an 
> HTTP issue, not purely a WebDAV issue, and is being addressed in 
> [I-D.draft-whitehead-http-etag]."
>
> ...which is incorrect in that there has been no activity on that draft 
> for almost one year (new issue: 
> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=265>).
Agreed.
>
>> s9.6.1: I think it would be helpful to explicitly list which properties
>> are not returned because of the way allprop is defined.
>
> 9.1.6.
>
> That's hard to do, because all of the properties defined in RFC2518 
> are returned.
In that case I misunderstood the purpose of the example.  I thought it
was intended to show that some properties didn't come back with allprop.
Maybe the example could be extended to demonstrate this in some way (and
make it clear what didn't come back).

Regards,
Elwyn
> Best regards, Julian

Received on Wednesday, 7 February 2007 14:12:04 UTC