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 10:21:11 -0800
Message-ID: <CABP7Rbf0tfXiABAZoQOQ31XunCiiGfYjDasaCKK0BJtZN3bg0A@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>
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?

- James

>>>> That said, here's a compromise: Let's expand the uniqueness constraint
>>>> to include anchor, hreflang and type. Doing so ought to cover the vast
>>>> overwhelming majority of the possibly viable use cases. I can also say
>>>> that the server MUST consider the remaining target attributes to be
>>>> significant in that, *if* the server chooses to surface those links in
>>>> some representable manner, the most recently received values for those
>>>> MUST be included. Is that better?
>>>
>>>
>>>
>>> I don't think it resolves the issue...
>>>
>>
>> Is it at least a step in the right direction?
>
>
> Well yes, it includes more parameters, but what I'm mainly concerned with
> parameters that we don't know yet.
>
> Best regards, Julian
Received on Wednesday, 6 November 2013 18:21:58 UTC

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