Re: Updated Protocol draft available

This is covered, if briefly, in section 5 on error conditions.

I don't recall a specific discussion in LDP about the error conditions, but
the common response I've heard is:

410 assumes additional knowledge about the past state of the resource, e.g.
that it used to exist and does not any longer, which is an additional
implementation requirement for no practical benefit beyond the stateless
404 response.

Further, though less convincing to me personally, with the ability of the
client to request a URI slug, it might be possible and desirable to
over-write previously existing annotations.  Another situation might be
privacy or liability -- there could be reasons why admitting that an
annotation used to exist at a particular URI is undesirable.

I think we have this well in hand by simply referring to the options in
section 5, and letting implementers decide which is most appropriate for
their situation.

Rob










On Thu, Jun 18, 2015 at 2:34 AM, Ivan Herman <ivan@w3.org> wrote:

> Sounds good indeed!
>
> I wonder why the LDP document is silent on this, I must admit. But we can
> still add it as an additional constraint.
>
> Cheers
>
> Ivan
>
>
> > On 18 Jun 2015, at 11:32 , Doug Schepers <schepers@w3.org> wrote:
> >
> > Hey, Ivan–
> >
> > On 6/18/15 5:14 AM, Ivan Herman wrote:
> >>
> >> - Still with DELETE, it is not clear what really happens with the
> >> resource itself. Pragmatically, what should the server respond if a
> >> GET is issued with the URI of the deleted annotation. The LDP
> >> document forwards to the relevant RFC:
> >> https://tools.ietf.org/html/rfc7231#section-4.3.5 which actually
> >> leaves this issue open. Should we keep it open, or should we define
> >> what should happen in such case (possibilities are to return a 404,
> >> or a 204 (no content). I have not made up my mind on this, just
> >> flagging the question. (I am mildly in favour of 404, although I do
> >> not like the fact that a URI, ie, the URI of the original annotation,
> >> is still around and would lead to a 404. On the other hand, if it is
> >> not a 404 then it would suggest that the URI can be reused through a
> >> PUT, which may not be a good idea and it would also force the server
> >> to check whether the resource is listed in the container.)
> >
> > How about 410: Gone?
> >
> >
> > RFC7231 [1]:
> > [[
> > 410 Gone
> >
> >   The 410 (Gone) status code indicates that access to the target
> >   resource is no longer available at the origin server and that this
> >   condition is likely to be permanent.  If the origin server does not
> >   know, or has no facility to determine, whether or not the condition
> >   is permanent, the status code 404 (Not Found) ought to be used
> >   instead.
> >
> >   The 410 response is primarily intended to assist the task of web
> >   maintenance by notifying the recipient that the resource is
> >   intentionally unavailable and that the server owners desire that
> >   remote links to that resource be removed.  Such an event is common
> >   for limited-time, promotional services and for resources belonging to
> >   individuals no longer associated with the origin server's site.  It
> >   is not necessary to mark all permanently unavailable resources as
> >   "gone" or to keep the mark for any length of time -- that is left to
> >   the discretion of the server owner.
> >
> >   A 410 response is cacheable by default; i.e., unless otherwise
> >   indicated by the method definition or explicit cache controls (see
> >   Section 4.2.2 of [RFC7234]).
> > ]]
> >
> > Wikipedia [2]:
> > [[
> > 410 Gone
> >    Indicates that the resource requested is no longer available and will
> not be available again. This should be used when a resource has been
> intentionally removed and the resource should be purged. Upon receiving a
> 410 status code, the client should not request the resource again in the
> future. Clients such as search engines should remove the resource from
> their indices. Most use cases do not require clients and search engines to
> purge the resource, and a "404 Not Found" may be used instead.
> > ]]
> >
> > [1] https://tools.ietf.org/html/rfc7231#section-6.5.9
> > [2]
> https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error
> >
> > Regards–
> > –Doug
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>
>


-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305