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

[Julian Reschke <[e-mail]>]

Elwyn Davies schrieb:
> 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.

Ok, will do (meaning: I agree with this point of view and will make 
changes accordingly in "my" draft, which is *not* the WG draft).

>>> 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 :-)

OK, Section 3. Now the issue still is that to define the depth header, 
you need to understand collections, which only have a forward reference 
in Section 3.

Also, the real meaning of the "Depth" request header varies with 
requests. In particular, its usage in the context of LOCK is really 
different from what we do with, for instance, PROPFIND or COPY.

Thus, this probably should be fixed inside the Locking section (for 
which there have been proposals for a complete rewrite, for that matter).

>>> 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...'?

+1.

>>> 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).

We have an example for allprop vs live properties not being returned - 
in this case live properties defined in RFC3253 - in Section 9.1.4. That 
being said, we probably should minmally re-arrange the examples so that 
9.1.4 comes after 9.1.6 (9.1.4 being a special case of allprop).

Best regards, Julian


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art