Subject: [core] Accept option and intermediaries

From: Klaus Hartke <[email-masked]>
Date: Wed, 6 Feb 2013 00:40:09 +0200

The rules for handling the Accept option in a request are quite well
defined for an origin server:

- If the origin server implements the Accept option, it checks if a
response with an acceptable content-format is available (in order of
the client's preference) and, if yes, returns that. Otherwise, it
either returns an error response or a response with an unacceptable
content-format (which is basically the same, as the client doesn't get
what it wants).

- If the origin server does not implement the Accept option, it
returns a response which either happens to have an acceptable
content-format or otherwise an unacceptable content-format.

But what about intermediaries?

Here are three examples that I'm not sure of:

1.
The client sends a request with
     Accept: 42
     Accept: 43
The intermediary has a stored response with
     Content-Format: 43
in its cache as the result of a request with
     Accept: 43
Is the intermediary allowed to return the stored response, or does it
have to make a request to the server?

2.
The client sends a request with
    Accept: 42
    Accept: 43
The intermediary has a stored response with
    Content-Format: 44
in its cache as the result of a request with
     Accept: 44
Is the intermediary allowed to return the stored response, or does it
have to make a request to the server?

3.
The client sends a request with
    Accept: 42
    Accept: 43
The intermediary has a stored response with
    Content-Format: 44
in its cache as the result of a request with
    Accept: 43
Is the intermediary allowed to return the stored response, or does it
have to make a request to the server?

Best regards,
Klaus

---

From: Bert Greevenbosch <[email-masked]>
Date: Wed, 6 Feb 2013 02:17:40 +0000

Hi Claus,

I think your examples do not have a fixed answer. Especially, Section 5.10.4 in the CoAP spec uses "SHOULD" in the text about returning an error when the requested content-format cannot be used:

{
  The server SHOULD return one
  of the preferred Content-Formats if available. If none of the
  preferred Content-Formats can be returned, then a 4.06 "Not
  Acceptable" SHOULD be sent as a response.

  Note that as a server might not support the Accept option (and thus
  would ignore it as it is elective), the client needs to be prepared
  to receive a representation in a different Content-Format. The
  client can simply discard a representation it cannot make use of.
}

This means that you cannot reliably determine whether a response in another content-type than was requested through the "accept" option is due to the server not supporting the "accept" option, or due to it not being able to deliver the requested content-type.

As for why is it is a "SHOULD" here I am not certain. Maybe the "SHOULD" is to ensure non-supporting servers do not violate normative text. This would make this an editorial issue.

Having said that, I think the following behaviour would make most sense:

{
  1.
}

The intermediary MAY return the cached response. Even though the content-format 42 may be more suitable, the client will be fine with receiving 43. However, the intermediary should be allowed to choose, as it may know that content-format 42 is better than 43.

{
  2.
}

Forward to the server. The cached response with content-format 44 is irrelevant for this request.

{
  3.
}

Forward to the server, as we don't know if the server does not support content-type 43 or does not support "accept". Therefore the server may be able to deliver content-type 42. This one would be clearer if we rephrased the above text to MUSTs for supporting servers. Then the cached response could have been re-used.

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: 06 February 2013 06:40
To: [email-masked] WG
Subject: [core] Accept option and intermediaries

1.

2.

3.

Best regards,
Klaus
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 6 Feb 2013 13:01:55 +0000

+1 for Bert's answers.

It would be clearer to rephrase 5.10.4. to (if this is meant, in fact):
 - servers not supporting Accept just ignore it
 - servers that do support Accept: "MUST return one of the preferred Content-Formats if available.  If none of the
   preferred Content-Formats can be returned, then a 4.06 "Not Acceptable" MUST be sent as a response.

For question #1 indeed the intermediary would make an implementation-specific choice, as more detailed guidance on this choice is not in core-coap right now. I assume that's not an issue since the client can understand the less-preferred format too.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert Greevenbosch
Sent: Wednesday 6 February 2013 3:18
To: Klaus Hartke; [email-masked] WG
Subject: Re: [core] Accept option and intermediaries

Hi Claus,

{

{
  1.

{
  2.

{
  3.

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: 06 February 2013 06:40
To: [email-masked] WG
Subject: [core] Accept option and intermediaries

The rules for handling the Accept option in a request are quite well defined for an origin server:

- If the origin server implements the Accept option, it checks if a response with an acceptable content-format is available (in order of the client's preference) and, if yes, returns that. Otherwise, it either returns an error response or a response with an unacceptable content-format (which is basically the same, as the client doesn't get what it wants).

- If the origin server does not implement the Accept option, it returns a response which either happens to have an acceptable content-format or otherwise an unacceptable content-format.

1.
The client sends a request with
     Accept: 42
     Accept: 43
The intermediary has a stored response with
     Content-Format: 43
in its cache as the result of a request with
     Accept: 43
Is the intermediary allowed to return the stored response, or does it have to make a request to the server?

2.
The client sends a request with
    Accept: 42
    Accept: 43
The intermediary has a stored response with
    Content-Format: 44
in its cache as the result of a request with
     Accept: 44
Is the intermediary allowed to return the stored response, or does it have to make a request to the server?

3.
The client sends a request with
    Accept: 42
    Accept: 43
The intermediary has a stored response with
    Content-Format: 44
in its cache as the result of a request with
    Accept: 43
Is the intermediary allowed to return the stored response, or does it have to make a request to the server?

Best regards,
Klaus

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 6 Feb 2013 15:35:31 +0200

> +1 for Bert's answers.

I agree with Bert's conclusions on the examples as well.

But it looks like implementing this properly in an intermediary could
become quite complex. The outcome does not only seem to depend on the
Content-Format of the stored response(s), but also on the Accept
Options of the requests that led to the stored responses. I'd like to
see this more fleshed out, not necessarily in the draft. Has anyone
implemented this already and can share their experience?

>    preferred Content-Formats can be returned, then a 4.06 "Not Acceptable" MUST be sent as a response.

There is nothing that stops a server from supporting a feature for one
request and not supporting it for the next request...

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Feb 2013 14:49:47 +0100

> But what about intermediaries?

I think it is pretty clear that an intermediary must treat Accept as a cache-key.
(This is also consistent with coap-13 marking it neither UnSafe nor NoCacheKey.
Yes, this only governs the case where an intermediary does not understand the option, but it is still good to know it's consistent.)

> have to make a request to the server?

Not without checking that the request that gave it the 43 also asked for [42,43].
Practical example:
43 may be a "fallback representation" that only contains some of the data.
The previous request that gave us the cache entry may have asked for [43] only, so the server was forced to send back the 43.
(Well, it was allowed to ignore the Accept, but of course that is not the intention of the request, so a good implementation would not do that.)
The server may well be able to send a 42 if allowed to do so by the request.

> have to make a request to the server?

No and yes.

> have to make a request to the server?

No and yes.

Grüße, Carsten

PS.: Re Bert's and Esko's response:
The MUST certainly is what we want a server implementation developer to understand here.
It is just hard to enforce this in the protocol (and it is thus hard for peers to rely on this property, which is the whole point of a MUST):
As Klaus said, the server can decide to support Accept only on Tuesdays or in odd seconds or based on some specific property of the request that is hard for a client to make out.
So it would not really be useful for a client to try to divine whether the server supports Accept (i.e., promises to always honor an Accept) or not, even if this were possible in a reliable way in the first place.
Add intermediaries in the mix if you aren't convinced yet.
So the MUST (= can rely on) is not what we want a client implementation developer to understand here!

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 6 Feb 2013 16:03:13 +0200

> I think it is pretty clear that an intermediary must treat Accept as a cache-key.

So, in other words, a resource is identified by the tuple (scheme,
host, port, path segments, query arguments, acceptable formats) and
not (scheme, host, port, path segments, query arguments), and a
response that was obtained from one set of Accept options MUST NOT be
used to satisfy a request for another set of Accept options?

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Feb 2013 15:48:33 +0100

On Feb 6, 2013, at 15:03, Klaus Hartke <[email-masked]> wrote:

> not (scheme, host, port, path segments, query arguments),

Well, it is still the same resource, it's just the the request included information about the specific representation desired.
This information cannot be ignored by a cache.  
(That's also why most Options that aren't UnSafe aren't NoCacheKey.)

> and a

That is what I'm saying, indeed.

So, what is the practical impact of not being able to perform the optimization that you seem to be implying here?
In the HTTP world, there are two uses of Accept that I have seen:
1) Indicating client capabilities in a browser.  This doesn't scale (browsers support a lot of media types now) and has largely been abandoned.
2) Asking for a specific media type that is different from the default media type, e.g., for a JSON representation instead of an HTML representation.

In 2, I haven't seen more than one media type asked for.  So the case you have been presenting wouldn't really occur in that usage.

Of course, HTTP usage is not necessarily indicative of CoAP usage.  I would expect we include media type capabilities in our discovery frameworks (indeed, RFC 6690 already has ct=) so there is little need for guesswork.  So I think it is even more likely that a CoAP client will request exactly the media type that it wants, based on what it already knows about the server.  This makes including that media-type into the cache-key the obviously desirable thing to do.  Second-guessing by intermediaries then never provides a performance improvement.  So let's not spend effort doing that.

Grüße, Carsten

PS.: yeah, s/media type/content format/ for the CoAP side... But the point is the same.

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 6 Feb 2013 17:21:24 +0200

Carsten Bormann wrote:
> In 2, I haven't seen more than one media type asked for.

Maybe we can tweak the Accept option a bit more into that direction?
Something along the lines of

- If the client doesn't ask for a specific media type, the server
returns the default media type + a set of of alternate media types
available at the request URI

- The client can ask for a specific media type using a critical,
non-repeatable If-Content-Format request option which causes the
server to return the specific media type or an error.

If the server doesn't want to support If-Content-Format, it wouldn't
advertise alternate media types.

Klaus

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 6 Feb 2013 15:46:42 +0000

Hi

> Carsten Bormann wrote:
> > 2) Asking for a specific media type that is different from the default media
> type, e.g., for a JSON representation instead of an HTML representation.
> >

This is also my experience and a while back Guido (AFAIR) and I were in favor of making the Accept option non-repeatable. It reduces complexity and usually constrained implementations cannot choose from a variety of available parsers. I also think that using the Link Format to list available Content-Formats is the way to go.

> - The client can ask for a specific media type using a critical, non-repeatable
> If-Content-Format request option which causes the server to return the
> specific media type or an error.

What about simply keeping the Accept option and "If none of the preferred Content-Formats can be returned, then a 4.06 "Not Acceptable" MUST be sent as a response." (When the server supports the elective Accept option.)

Ciao
Matthias

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 16 Feb 2013 10:42:56 +0200

Is there anything that can be done with Proactive Negotiation [1] that
cannot be done with Reactive Negotiation [2]?

That is, do we need Accept at all?

See also http://trac.tools.ietf.org/wg/httpbis/trac/ticket/81

Klaus

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-3.4.1
[2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-3.4.2

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 16 Feb 2013 10:11:10 +0200

> I think it is pretty clear that an intermediary must treat Accept as a cache-key.

What about PUT?

PUT replaces all representations of the resource with the new
representation. It doesn't just replace the first representation that
matches the Accept option. (The Accept option in a PUT request
actually negotiates the content-format of the action result
representation, not the representation that the request should be
applied to.) So a cache needs to be "smart" about Accept and cannot
simply treat Accept as a cache-key.

Klaus

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sat, 16 Feb 2013 15:16:41 +0000

> Klaus Hartke:
> Is there anything that can be done with Proactive Negotiation [1] that cannot be
> done with Reactive Negotiation [2]?
> 

Two problems I see is that having one URI per Content-Type blows up the link format a lot and weakens the resource abstraction. The latter results in a problem for PUT for instance: If we update one Content-Type resource via PUT, what does this mean for the other related resources? With a single resource and different supported representations this is clear.

Ciao
Matthias

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sat, 16 Feb 2013 15:26:57 +0000

> > I think it is pretty clear that an intermediary must treat Accept as a cache-key.

Is PUT cachable or what do you mean?

> PUT replaces all representations of the resource with the new representation. It
> doesn't just replace the first representation that matches the Accept option.
> (The Accept option in a PUT request actually negotiates the content-format of
> the action result representation, not the representation that the request should
> be applied to.) So a cache needs to be "smart" about Accept and cannot simply
> treat Accept as a cache-key.

PUT must invalidate all cache entries anyway. Here we have a major problem if we use separate resources for different Content-Types (cf. Reactive Negotiation) ...

Ciao
Matthias

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sat, 16 Feb 2013 15:40:06 +0000

> PUT must invalidate all cache entries anyway. Here we have a major problem if
> we use separate resources for different Content-Types (cf. Reactive
> Negotiation) ...

Okay, I just found this: http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-04
Do we want to go that far?

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 16 Feb 2013 18:11:19 +0200

Matthias Kovatsch wrote:
> Two problems I see is that having one URI per Content-Type blows up the link format a lot and weakens the resource abstraction.

Sure, there are some disadvantages; see -httpbis for more. The
question is, will there actually be so many constrained devices that
offer resources in multiple representation formats that the
disadvantages of reactive negotiation outweigh the disadvantages of
proactive negotiation?

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 16 Feb 2013 17:41:37 +0100

On Feb 16, 2013, at 17:11, Klaus Hartke <[email-masked]> wrote:

> disadvantages

Well, we usually won't have that much negotiation, because the selection will more likely happen at discovery.

It really comes down to whether you want servers to encode the selection of a format into the URI, or whether you want to have a standard way to associate multiple formats with a single URI.
Clearly, this is isomorphic from a functional point of view.  So, really, the questions are:

1) how likely is a server to provide multiple formats?

2) how much do we benefit from a standard way to identify the format that is separate from the URI?

Re 1: I think is it quite likely that sensors implementing SenML will provide multiple formats, including a text/plain style with some raw data.

The one thing that is really swaying me into keeping Accept is the potential for converting proxies.
That is impossible to do in a general way when you leave the URI encoding of the desired format to each server.

Can we simplify Accept some more?

Making it a single choice is unlikely to simplify origin servers much, as there is very little difference between rejecting a single choice and stepping through a number of them.
(i.e., this would replace a single while loop by a single if condition, saving one jump or so.)
For a cache, of course, there is additional complexity, as the discussion here is showing.  
Simply accepting that a cache has to treat different Accept combinations separately reduces that complexity a lot, though.

So I'm still not convinced we want to change anything.
But, yes, Accept is not strictly necessary, if you don't think application-agnostic converting proxies are valuable.
And the use cases for multi-valued accept are more sparse than those for single-valued Accept, but then the complexity is rather limited.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 16 Feb 2013 19:16:01 +0200

> The one thing that is really swaying me into keeping Accept is the potential for converting proxies.

How would that look like?

Assuming a client sees a link that indicates that the link destination
is available in application/senml+xml. Should it send

    Accept: application/senml+exi, application/senml+xml@gzip,
application/senml+xml

in the hopes that there is a proxy along the way that performs the
conversion to one of the unavailable but preferred formats?

If there is no converting proxy, then requests from clients indicating
different unavailable but preferred formats would always hit the
server, even though each request invariably results in the same
application/senml+xml response.

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 16 Feb 2013 18:20:42 +0100

> How would that look like?

Most likely by the proxy taking part in the resource directory game.
(So, again, most likely the client is sending a single-valued Accept, based on what it knows from discovery about the proxy.)

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 16 Feb 2013 19:32:04 +0200

> Most likely by the proxy taking part in the resource directory game.

Is it still an application-agnostic converting proxy then?

> (So, again, most likely the client is sending a single-valued Accept, based on what it knows from discovery about the proxy.)

That sounds like an argument for reactive negotiation.

Btw I'm not sure if we should rely too much on .well-known/core for
discovering everything. Non-link-format documents can contain links,
too.

Klaus

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Mon, 18 Feb 2013 16:49:11 +0000

> > (So, again, most likely the client is sending a single-valued Accept,
> > based on what it knows from discovery about the proxy.)
> 

I am still in favor of using a non-repeatable Accept option together with Link Format information. This comes pretty close to reactive negotiation with having a standardized way to select the preferred Content-Format.

1) Reactive negotiation with URIs would require linked caches and the server-side behavior of PUT to one of the linked resources is still undefined. Accept simplifies this. On the Web multiple resources make more sense, as different formats are often created manually and can evolve independently (e.g., a (non-)Flash version of a site). In M2M, there is usually a single data model behind different simple format-encoders.
(Without Accept, I would probably implement some coap://example.com/some/resource.type convention that has a single resource handler for all possible types given through the Uri-Path. So why not Accept directly?)

2) A repeatable Accept option is prone to blowing up the number of observe relationships through an intermediary. We already discussed the problem of permuted Accept lists. If the client is supposed to merge observe relationships, as Klaus suggested, it must be able to decide which Accept combinations are equivalent. This would require probing and cancelling relationships again. Thus, let us simplify things with a non-repeatable Accept option.

3) Currently the Accept option is the only integer array and requires its unique piece of code. Having implemented CoAP for constrained platforms, I would be very happy to get rid of that. In my experience, and apparently Carsten's as well, multiple Accept options are not very likely in M2M applications, anyway.

> discovering everything. Non-link-format documents can contain links, too.

These links can also contain Link Format information as attributes, no?

Ciao
Matthias

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 18 Feb 2013 21:12:02 +0200

OK, it seems there are two places involving content negotiation in CoAP:

1. Servers that offer resources in multiple representation formats. As
Matthias said, the representations will likely source from the same
data and therefore don't exhibit the problems of, e.g., multi-language
web pages.

2. Intermediaries that offer additional representation formats for the
resources accessed through them.

If either of this is common enough, then I agree that having an
Accept-parametrizable resource would be the cleanest solution.
Although not part of the URI, different representations could be
addressed by specifying the representation format along the URI in a
link.

My question is, how the client gets the best possible representation
format that is available for it.

One option is to provide one link for each available format. (This can
be encoded very efficiently in a link-format document by creating one
link with multiple ct attributes.) But then you'd would have to update
all links in existence every time you add or remove a format, which
may be difficult if there are links to your resource that are served
by a server not under your control.

For the application-agnostic converting proxy, the problem is that
there naturally won't be any links with the additional formats.
Carsten seemed to imply that such a proxy could rewrite
.well-known/core to add additional formats. But I guess it won't
rewrite all links in all formats, since it's application-agnostic.

I strongly oppose the idea of having to retrieve .well-known/core
before I can interact with a resource that I discovered by following a
link from somewhere else.

Another option is to provide the available formats in the
representations of the resource, or in a CoAP option that the server
sends along the representation. Then, discovery of the available
formats is decoupled from the discovery of the resource itself. If a
client follows a link and then discovers that the resource is also
available in better formats, it can easily switch to the best one.

A third option is to let the client include all supported formats in
its request; the server returns the representation in the best format
that is available. With this option, the client doesn't have to
discover the available formats at all, and the converting proxy can
easily convert a representation returned by a server to a better
format. However, the list of supported formats might be quite long and
overall this breaks caching.

To me, the second option looks best. If there is consensus to keep the
Accept option (which there seems to be), then I'd support limiting it
to one instance and providing the alternate formats in the
representation or along the representation in a CoAP option (without
affecting the ability to specify representation formats in links).

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 18 Feb 2013 20:27:29 +0100

> link from somewhere else.

Retrieving the link-format information *after* discovery is wrong; I'd agree with that.

> sends along the representation.

Again, this information should be made available as part of the discovery, not something that is delivered with each retrieval of a resource representation.

> Then, discovery of the available
> formats is decoupled from the discovery of the resource itself.

Why is that such a good thing?

> If a

There have been several suggestions already for a "give me metadata" type request for a resource.
E.g., draft-greevenbosch-core-profile-description-01.txt; there also was a proposal for finding out the methods that can be applied to a resource.
I'm not yet convinced we need any of these, but I'd discuss a "which formats are you available in" request in the context of these.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 18 Feb 2013 22:16:22 +0200

> Why is that such a good thing?

As I tried to explain, discovery of a resource does not necessarily
happen through .well-known/core. I think it's unlikely that all links
from all servers to a resource will always provide up-to-date
meta-data on the link destination (size, formats, ...). In that case,
indicating the available formats in the representations or in a CoAP
along the representation allows the client to get the best possible
representation format that is available for it, which it otherwise
could only discover by retrieving .well-known/core first.

> I'm not yet convinced we need any of these

Agreed. The methods allowed for a resource are typically discovered by
following links in the representation of the resource. For example, a
resource that is updatable would include a link in its representation
that indicates where to PUT the new information and what
representation formats are acceptable. So I see no need for
discovering the allowed methods through .well-known/core, an OPTIONS
method or any other mechanism.

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 19 Feb 2013 09:12:52 +0100

> PUT must invalidate all cache entries anyway. Here we have a major problem if we use separate resources for different Content-Types (cf. Reactive Negotiation) ...

Exactly: going towards multiple URIs for different representations of one resource just conveniently makes PUT invalidation impossible, "solving" this problem.

PUT invalidation is a bit of a luxury item anyway.

If there are two caches talking to an origin server, only the client of one of them will benefit from PUT invalidation.
(If there is any other transaction invalidating the resource as a side effect, no one will benefit from PUT invalidation.)
Any approach that *relies* on PUT invalidation to kick in is not going to work.

(According to the protocols 101 principle on when you can put in a MUST*), this means the MUST is out of place.  But I'm not arguing for turning it into a quality of implementation note.)

Grüße, Carsten

*) You can put in a MUST in either of the two following cases:
1) the required behavior prevents the network from blowing up, a bank from being robbed, etc.
2) the required behavior allows the protocol peer to rely on this behavior, providing some benefit that outweighs the onus of the MUST.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 19 Feb 2013 09:16:42 +0100

On Feb 18, 2013, at 21:16, Klaus Hartke <[email-masked]> wrote:

> The methods allowed for a resource are typically discovered by
> following links

Why do you believe the links will expose the methods and not the format?
I know HTML works this way, but is this relevant for how we expect CoAP clients to obtain links?
If it is truly beneficial to know the complete set of available formats, other links than the ones in link-format could also supply this information.
(We already have the link target attribute for that, "ct".)

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 19 Feb 2013 11:56:24 +0200

> (We already have the link target attribute for that, "ct".)

There is a difference between

A) a resource making a statement about another resource (possibly on a
different server),

B) a resource making a statement about itself, and

C) .well-known/core making a statement about a resource hosted on the
same server.

The state of a resource can change over time, and so does its
meta-data like representation size, available representation formats
and if and how the resource can be changed.

When a client retrieves .well-known/core, it is fair to assume that
the meta-data embedded in the links is accurate at the time of the
request. So the client can, for example, select the best
representation format. Similarly, if a client retrieves a
representation of a resource that indicates that the resource is in a
state in which it can be deleted, the client can use this information
to delete the resource.

But if a resource links to another resource, it's unreasonable to rely
on the assumption that the embedded meta-data reflects the current
state of the linked resource, in particular if the linked resource is
on a different server. Unless the server retrieves the link
destination or .well-known/core before generating the link, it does
not know the size of the current representations, whether new (better)
representation formats are available or if the resource is in a state
in which it can be changed.

After all, link attributes are just hints, not promises. If a link
makes an outdated statement about the representation size, I can still
retrieve the representation. If a link makes an outdated statement
about the state of a resource, I can learn if the resource is
updatable/deletable by retrieving a representation of the current
state and go from there. So, if a link makes an outdated statement
about available representation formats, I should be able to discover
new formats that have become available in the meantime and should not
be required to retrieve .well-known/core as the only way to learn
them.

Klaus

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 19 Feb 2013 11:45:49 +0000

> The state of a resource can change over time, and so does its meta-data like
> representation size, available representation formats and if and how the
> resource can be changed.

I just want to remark that the metadata is not that likely to change, so they are very good hints. The size denotes an estimated upper bound (maybe linked to the maximum buffer size the server can support for this resource) and the format is linked to the encoders implemented in the firmware (which despite the Block use case will not change that often :) ). Your case sounds more like a RESTful clipboard where the server is agnostic of the data stored at a resource.

Ciao
Matthias

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 19 Feb 2013 14:05:57 +0200

Matthias Kovatsch wrote:
> I just want to remark that the metadata is not that likely to change, so they are very good hints.

Not if you add application-agnostic converting proxies to the mix.

And resources linking to different servers will likely not provide
these hints at all.

Klaus