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>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC