RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

Since the general consesus of the list is to do away with LNRs as we know
them, if you can't beat em, join em :-)

It makes sense for 201 to be the response for LOCKing an unmapped URL. This
was discussed a while ago.

I think Jim said he would add this to the issues list. Jim ?

Regards

Shaun Hall
Xerox Europe

> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Sent: 10 August 2001 09:26
> To: Jason Crawford; Lisa Dusseault
> Cc: Clemm, Geoff; w3c-dist-auth@w3.org
> Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
> 
> 
> For me, an addition to the Status Codes (currently Sec. 8.10.7)
> would suffice. A la
> 
> 201 (Created) - The lock request succeeded by creating a new resource
> and the value of the lockdiscovery property is included in the body.
> 
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> > Sent: Thursday, August 09, 2001 9:12 PM
> > To: Lisa Dusseault
> > Cc: Clemm, Geoff; w3c-dist-auth@w3.org
> > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
> >
> >
> >
> >
> >
> > It sounds like we all agree with Geoff's wording.
> >
> > Lisa did make an interesting observation below though.
> >
> > <<
> > This means that LOCK can return 201, which is important to 
> distingusih
> > between LOCK of an unmapped URL (I can go ahead and put my 
> content) and
> > LOCK
> > of URL that somebody else just created (I should NOT send my
> > content before
> > checking).
> > >>
> >
> > Do we want to enhance Geoff's explanation or add a comment 
> along the lines
> > of Lisa's observation?   Or just make sure we mention 201 
> where we list
> > potential error codes for LOCK requests?
> >
> > J.
> >
> >
> >
> >
>

Received on Friday, 10 August 2001 06:15:52 UTC