Subject: Re: [core] #202: Remove the 270 byte artificial limit

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 Apr 2012 09:27:01 -0600

I'm not a fan to removing the limit. Thought we could do it, I don't see the need for doing it and I think it will increase the number of bugs and reduce interoperability where one person assumes a limit of 1024 and someone else assumes 65k. 

On Mar 28, 2012, at 6:27 AM, core issue tracker wrote:

> #202: Remove the 270 byte artificial limit
> 
> For a while, it seemed we had consensus to leave in the artificial limit
> of 270 bytes for the option length.  However, this left a scar on Uri-
> Proxy, which needed special handling for the rare case where this creates
> a problem.
> 
> Matthias Kovatsch has now proposed a simple way to remove the artificial
> limitation, which is documented in section 2.1 of
> 
>        http://tools.ietf.org/html/draft-bormann-coap-misc-14#section-2.1
> 
> This change will also enable the reverting of Uri-Proxy to its natural
> state of a  non-repeatable option.
> 
> -- 
> -----------------------------+------------------------------------
> Reporter:  cabo@…           |      Owner:  draft-ietf-core-coap@…
>     Type:  protocol defect  |     Status:  new
> Priority:  minor            |  Milestone:
> Component:  coap             |    Version:
> Severity:  In WG Last Call  |   Keywords:
> -----------------------------+------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/202>
> core <http://tools.ietf.org/core/>
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 18 Apr 2012 18:05:42 +0200

> I'm not a fan to removing the limit. Thought we could do it, I don't see the need for doing it and I think it will increase the number of bugs and reduce interoperability where one person assumes a…

Two observations:

1) There is a gross upper limit on all this: datagram size.  This is currently constrained by the lack of Path MTU discovery to 1280.

2) 270 was deemed too low for the Proxy-Uri option.  We now have a special case just for that, which already has all the unpleasant properties you describe.  Instead of doing another special case for every new option that might come up, doing this once is more attractive.  Or we might get rid of the Proxy-Uri special case!

Grüße, Carsten

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 Apr 2012 11:29:04 -0600

> 2) 270 was deemed too low for the Proxy-Uri option.  We now have a special case just for that, which already has all the unpleasant properties you describe. Instead of doing another special case fo…

so my key concern is we have a well defined limit. I'm less concerned about the value of that limit other than any client knows that  the server will support things up to that limit. 

But tell my why 270 is too low for Proxy-URI? I'm unconvinced - I will point out that at there is some argument that

goo.gl/x6YHG

is about as long a you really need for HTTP URLs.

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 18 Apr 2012 19:18:58 +0000

> is about as long a you really need for HTTP URLs.

This is like going back to ZigBee's binary cluster identifiers.
People are, however, pretty bad in handling this machine gibberish and thus need a long time to understand the components and to integrate systems. This is why self-descriptive URIs are so nice and in turn why the Web took off as it did.
	
Regards
Matthias

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Apr 2012 14:18:17 -0600

> People are, however, pretty bad in handling this machine gibberish and thus need a long time to understand the components and to integrate systems. This is why self-descriptive URIs are so nice and…

I agree and I would not suggest a limit of 15 bytes for a URL. But I do think some limit is need for practical implementations and once we have a limit, we need to have some agreement on what it is. Given the URL are primarily for machine not human consumption, it seems like they can easily be designed to be relatively short and and still easy for a human to debug.

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sat, 21 Apr 2012 17:20:40 +0000

> But I do think
> some limit is need for practical implementations and once we have a limit, we
> need to have some agreement on what it is. Given the URL are primarily for
> machine not human consumption, it seems like they can easily be designed
> to be relatively short and and still easy for a human to debug.

The implementations could decide that through the applications they shall support.
A server for instance must only support its own longest hostname/Uri-Path/Uri-Query.
Clients could use the limitations from application profiles such as SEP 2.0 or IPSO.

I think it would generally be best, if such profiles would specify limitations and the protocol itself can be kept flexible, without artificial limitations.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Apr 2012 05:53:12 -0700

> I think it would generally be best, if such profiles would specify limitations and the protocol itself can be kept flexible, without artificial limitations.

So let me get this right, your think SEP 2.0 should define a limit but IETF should not? What happens when I want to buy a COAP stack and use it for both a SEP and IPSO profile?

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Mon, 23 Apr 2012 17:49:28 +0000

> > I think it would generally be best, if such profiles would specify limitations
> and the protocol itself can be kept flexible, without artificial limitations.
> 
> So let me get this right, your think SEP 2.0 should define a limit but IETF
> should not? What happens when I want to buy a COAP stack and use it for
> both a SEP and IPSO profile?

I would not buy it in the first place when the limit is hardcoded...
As I said, I think the limit is purely application-specific and probably technically caused by the hardware you use. But if you want to support 1k URIs, you have to pick the right platform.

The overall stack has so many parameters and choices that have to be harmonized and this is done by profiles.
 AFAIK, HTTP also has no limitation (only some too long error codes).
So, I still not see why we need that limitation.