W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: [apps-discuss] FYI: LINK and UNLINK

From: James M Snell <jasnell@gmail.com>
Date: Wed, 6 Nov 2013 11:56:15 -0800
Message-ID: <CABP7RbfADN8U5bff7hMvPLf8E_oB+GzjTSm1t8izov7XeHK0NQ@mail.gmail.com>
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>

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

- 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC