- From: James M Snell <jasnell@gmail.com>
- Date: Wed, 6 Nov 2013 11:56:15 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mark Nottingham <mnot@mnot.net>, IETF Apps Discuss <apps-discuss@ietf.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
http://www.ietf.org/id/draft-snell-link-method-07.txt Per Julian's suggestion, accommodates all target attributes, deals with 2xx response codes, handles use of the anchor attribute to override the context IRI. Also, deals with equivalence checking for IRIs. - James On Wed, Nov 6, 2013 at 10:31 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2013-11-06 10:21, James M Snell wrote: >> >> On Wed, Nov 6, 2013 at 10:05 AM, Julian Reschke <julian.reschke@gmx.de> >> wrote: >> [snip] >>> >>> >>> I don't see the material difference. >>> >>> If the client has no reliable way to find out what links are there it'll >>> be >>> essentially restricted to edit those that it created itself. >>> >>> It seems that this is the issue that needs to be addressed. >>> >>> >> >> This is not a problem I intend to solve... largely because I have no >> need to solve it. For one set of use cases I have, there is no need to >> discover established links, and for the remaining set, the data >> formats used already have ways of exposing whatever links the server >> wishes to expose. >> >> That said, have a concrete suggestion? > > > Maybe have a keyword for the "Prefer" header field that instructs the server > to return *all* links upon GET? > > Best regards, Julian > >
Received on Wednesday, 6 November 2013 19:57:02 UTC