RE: rfc2518-bis-04 issues (part 2)

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Jason Crawford
> Sent: Wednesday, July 30, 2003 6:36 PM
> To: Julian Reschke
> Cc: w3c-dist-auth@w3.org
> Subject: RE: rfc2518-bis-04 issues (part 2)
>
> ...
>
> > 02-C05 Section 6.3, p3
> >
> > Replace
> >
> > "However resources are free to return any URI scheme so long as it meets
the
> > uniqueness requirements."
> >
> > by
> >
> > "However servers are free to use any IETF-registered URI scheme so long
as
> > it meets the uniqueness requirements."
> >
> > (If it's not IETF-registered, I don't see how it can possibly meet the
> > uniqueness criterium).
>
> I'd vote to leave the text as it is.

Again, please help me understand...:

1) Are you suggesting that to for a scheme to be IETF-registered is not a
requirement? In which case I'll argue that by definition there can't be any
uniquess guarantee otherwise.

2) Are you suggesting that this is obvious? I which case I'll have to point
out that there are well-known server implementations doing just that, so
obviously the spec  hasn't been clear enough about that.


> > 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.
> Perhaps I misunderstand the existing text, but I also suspect the
> "unless it overwrites..." part is wrong.  If you do a MOVE and it's
> actually a different resource in that slot, I think you do need the parent
> collection's lock token.  It's only a PUT that doesn't require it.

Correct.

> > C02-30) Section 14.7
> >
> > "A change in a property SHOULD NOT cause the last-modified date to
change,
> > because clients MAY rely on the last-modified date to know when to
overwrite
> > the existing body."
> >
> > I think this is a new requirement that hasn't been discussed. BTW: it's
> > inconsistent with the attempt to make ETags a MUST -- if you have Etags,
you
> > don't have to rely on the last modified date anyway.
>
> I don't know if we discussed it or not, but the wording that is there
seems
> fine.  I do lack any compelling test cases to drive this issue in a
particular
> direction though.  I will rhetorically ask what non-WebDAV browsers do
> with ETags and lastmoddate.

It's a procedural question. I think *any* change to RFC2518 (and this is a
change) should appear on the issues list, indicating when and why it was
raised as an issue, and what conclusion was reached. As far as I know, this
hasn't happened.


Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 30 July 2003 14:23:34 UTC