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

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Feb 2007 15:11:40 +0100

(fyi)

-------- Original-Nachricht --------
From: - Mon Feb 05 05:29:34 2007
helo=[127.0.0.1])	by smtp.aaisp.net.uk with esmtps 
(TLSv1:AES256-SHA:256)	(Exim 4.62)	(envelope-from 
<[email-masked]>)	id 1HDfaw-0006l8-G4; Sun, 04 Feb 2007 11:31:42 
+0000
Message-ID: <[email-masked]>
Date: Sun, 04 Feb 2007 11:32:29 +0000
From: Elwyn Davies <[email-masked]>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Julian Reschke <[email-masked]>
CC: WebDAV <[email-masked]>,  [email-masked]
Subject: Re: [Fwd: Gen-art last call review of 
draft-ietf-webdav-rfc2518bis-17.txt]
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Feb 2007 15:22:53 +0100

Julian Reschke schrieb:
> ...

Turns out that we need to reregister HTTP status codes as well ((see
<http://tools.ietf.org/html/rfc2817#section-7.1> and
<http://www.iana.org/assignments/http-status-codes>).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Feb 2007 15:17:30 +0100

>> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=264>).

Turns out that we also need to update the HTTP status code registry (see
<http://tools.ietf.org/html/rfc2817#section-7.1> and
<http://www.iana.org/assignments/http-status-codes>).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Feb 2007 14:12:13 +0100

> <http://www.iana.org/assignments/http-status-codes>).

OK, below are the proposed changes for the IANA Consideration section 
(see also 
<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=264> and 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#iana.considerations>):

+++
Section 21.1., para. 1:
OLD:

     This specification defines two URI schemes:

NEW:

     This specification defines two URI schemes (see [RFC3986] and
     [RFC4395]):

Section 21.3., para. 1:
OLD:

     The message header fields below should be added to the permanent
     registry (see [RFC3864]).

NEW:

     The message header fields below should be updated in the permanent
     registry (see [RFC3864] for the registration process, and [RFC4229]
     for the initial registration being updated by this specification).

        Note: the "Status-URI" header defined in Section 9.7 of [RFC2518]
        has been removed in this specification; its IANA registration
        should continue to reference RFC2518.

Section 22., para. 0:
OLD:

  22.  Acknowledgements

NEW:

  21.4.  HTTP Status Codes

     This specification defines the HTTP status codes

     o  207 Multi-Status (Section 11.1),

     o  422 Unprocessable Entity (Section 11.2),

     o  423 Locked (Section 11.3),

     o  424 Failed Dependency (Section 11.4) and

     o  507 Insufficient Storage (Section 11.5),

     to be updated in the registry at
     <http://www.iana.org/assignments/http-status-codes>.

        Note: the HTTP status code 102 (Processing) (defined in Section
        10.1 of [RFC2518]) has been removed in this specification; its
        IANA registration should continue to reference RFC2518.

  22.  Acknowledgements
+++

Best regards, Julian