Subject: Re: [core] What's to be presented to IESG in December?

From: Zach Shelby <[email-masked]>
Date: Mon, 1 Nov 2010 09:11:39 +0200

On Nov 1, 2010, at 12:14 AM, Peter Bigot wrote:

> On Sun, Oct 31, 2010 at 4:34 PM, Zach Shelby <[email-masked]> wrote:
> On Oct 29, 2010, at 3:37 PM, Peter Bigot wrote:
> 
> > I feel coap-block is unnecessary if one can defer to alternative protocols (and we will need Uri-Scheme back to enable that, which I very much want)
> 
> I don't agree that this has anything to do with CoAP, which is a transfer protocol. If you want to provide a link to a different protocol, this should be done in your resource representation (just like an HTML link). Alternatively, the CoRE link format would allow you to include links to other protocols. I absolutely do not agree that CoAP should be returning some header option redirecting a client to use some other protocol.
> 
> Could you clarify: are you saying that you don't want to require CoAP to redirect to another protocol in this case, or that you don't want CoAP to ever support redirection to another protocol?

CoAP is a transfer protocol, it is not in the business of redirecting to other protocols. Linking should be performed in your application, e.g.:

1. In the representation, just throw in the equivalent of an HTML link. 
2. In the CoRE link format, or any other link format of your choice. Heck, if you are going to use TFTP, just point your client to use that in the first place. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Nov 2010 09:51:42 +0100

As far as I know, we haven't made redirect a part of the CoAP state machine yet.
(At least, the "30x response code" alluded to in 3.2.5 hasn't been defined.)

Do we want to?
As with any addition to CoAP, I'd like to understand the use cases.

On the specific example (assuming that we indeed have a redirect mechanism and that this can redirect to a full URI including scheme):
Redirect to a protocol preferred for large representations would be appropriate if it were somewhat of a surprise that the resource representation suddenly is so large.  Otherwise, I agree with Zach, the resource that gave you the URI (i.e., resource discovery or some other resource representation) should have given you a URI with the right scheme in the first place.

Narrowing this down to surprises, this specific use case seems relatively narrow.
But that may just be my lack of imagination, and of course there may be other use cases for redirection.

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Mon, 1 Nov 2010 07:26:35 -0500

I missed that we didn't have the referenced 30x redirect code defined, so
hadn't thought of it as an addition.

OK, I see that perspective.  Off-hand use cases for redirect:

* Forward a permanent URI to the entity temporarily responsible for managing
it

* Delegating complex representation formatting activities to a service on
another (less constrained) node

* Enabling client metadata such as message size restrictions to influence
the delivery mechanism (including the transfer protocol)

* Routing an unauthorized request to a security service through which
authorization can be obtained

The technique has clearly been valuable in HTTP, but maybe it's irrelevant
or unnecessary in CoAP.

Peter

On Mon, Nov 1, 2010 at 3:51 AM, Carsten Bormann <[email-masked]> wrote:

> On the specific example (assuming that we indeed have a redirect mechanism
> and that this can redirect to a full URI including scheme):
> Redirect to a protocol preferred for large representations would be
> appropriate if it were somewhat of a surprise that the resource
> representation suddenly is so large.  Otherwise, I agree with Zach, the
> resource that gave you the URI (i.e., resource discovery or some other
> resource representation) should have given you a URI with the right scheme
> in the first place.
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Peter Bigot <[email-masked]>
Date: Mon, 1 Nov 2010 08:09:05 -0500

My thought was:  it's an IETF standard with over a decade's worth of
interoperable implementations that use a datagram transport to transfer
larger-than-one-datagram documents reliably using minimal client and server
resources.

A task and environment that seem to fit a CoAP need perfectly.  Nobody
agrees.  Wish somebody'd explain why.  Might help me make my comments more
relevant.

Peter

On Sun, Oct 31, 2010 at 4:59 PM, <[email-masked]> wrote:

>
> On 31 Oct 2010, at 21:34, Zach Shelby wrote:
> >
> > You have already indicated that you personally want to use TFTP for your
> application, fine.
>
> Why would anyone want to use tftp for _anything_?
>
>
> puzzled,
>
> L.
>
> Lloyd Wood
> [email-masked]
> http://sat-net.com/L.Wood
>
>
>
>

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 2 Nov 2010 18:24:30 +0100

Zach Shelby wrote:
> Now, it might really make sense to send a response code different than 200 for observe notifications. Something in the CoAP reserved range? Or would a new 2xx code make more sense as it could be weird to mix errors and success in the new 6xx range.

We need to keep in mind that there are not only 200 responses when
observing a resource.

A grammar for the stream of notifications could look like this:

    ( 200 | 304 )* ( 404 | 500 )?

200: The resource changed to a new state; the payload contains a
representation of the new state.

304: The resource changed to a new state; the Etag Option indicates
which cached state the resource changed to.

404: The resource was deleted.

500: The server encountered an unexpected condition which prevented it
from continuing the subscription.

There are possibly more response codes that'd make sense in the
context of observing resources.

So we would need a new response code for many of the existing response
codes. But I believe most implementations would treat them exactly
like their non-notification counterpart.

Klaus