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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
