Subject: [core] #241: Proxy safe to forward options

From: "core issue tracker" <[email-masked]>
Date: Mon, 11 Jun 2012 08:08:15 -0000

#241: Proxy safe to forward options

#choose ticket.new
  #when True
 As a conclusion to the Ticket #230 discussion in the June 4th interim
 call, we decided to solve the identification of options that a proxy can
 safely forward even if not understood.

 Proposal made that we have a rule that “safe to forward without
 understanding options” have a number of something like option number mod 7
 = 5. (of course more thought on 7 and 5 but you get the idea)
  #end
  #otherwise
    #if changes_body
Changes (by ):

    #end
    #if changes_descr
      #if not changes_body and not change.comment and change.author
Description changed by :
      #end

--
    #end
    #if change.comment

Comment(by undefined):

    #end
  #end
#end

-- 
----------------------------------+--------------------
 Reporter:  zach@…                |      Owner:  zach@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  minor                 |  Milestone:
Component:  coap                  |    Version:
 Severity:  -                     |   Keywords:
----------------------------------+--------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/241>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 11 Jun 2012 08:55:30 -0000

#choose ticket.new
  #when True

Changes (by zach@…):

    #end
    #if changes_descr
      #if not changes_body and not change.comment and change.author
Description changed by zach@…:
      #end

--
    #end
    #if change.comment

Comment(by zach@…):

 Text for a new Proxy-Elective class added to r685. Defined Proxy-Elective
 in the terminology, the Options section and the Proxy section. Left the
 formula for determining Proxy-Elective options TBD for now. As they are
 elective it would make sense for them to be even.

 Question: Can we identify any existing Proxy-Elective options already
 defined in the CoAP draft?
    #end
  #end
#end

-- 
----------------------------------+---------------------
 Reporter:  zach@…                |       Owner:  zach@…
     Type:  protocol enhancement  |      Status:  new
 Priority:  minor                 |   Milestone:
Component:  coap                  |     Version:
 Severity:  -                     |  Resolution:
 Keywords:                        |
----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/241#comment:1>
core <http://tools.ietf.org/core/>

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 11 Jun 2012 10:56:33 +0200

>  = 5. (of course more thought on 7 and 5 but you get the idea)

This leads us seamlessly to the next problem of what options
constitute the cache key. [1]

Without "safe to forward without understanding" options, all options
that a cache has to deal with are understood, because any unrecognised
option is removed or rejected before it reaches the cache. This allows
us to specify whether the option is part of the cache key or not in
the specification.

With "safe to forward without understanding" options, caches have to
deal with options they don't recognize. This means we have to to
specify whether the option is part of the cache key or not in the
message (e.g., option number mod 5 = 3).

Klaus

[1] see discussion in thread
<http://www.ietf.org/mail-archive/web/core/current/msg03178.html>

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 11 Jun 2012 11:06:17 +0200

>  Text for a new Proxy-Elective class added to r685.

>  - <t>Options fall into one of two classes: "critical" or "elective".
>  - The difference between these is how an option unrecognized by an
>  - end-point is handled:
>  + <t>Options fall into one of three classes: "critical", "elective" or
>  + "proxy-elective". The difference between these is how an option
>  + unrecognized by an end-point or intermediate is handled:

Uhm, no. "critical"/"elective" and "safe to forward without
understanding"/"not safe to forward without understanding" are
orthogonal.

So there are four classes:

- critical, not safe to forward without understanding
- elective, not safe to forward without understanding
- critical, safe to forward without understanding
- elective, safe to forward without understanding

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 11 Jun 2012 11:11:38 +0200

Klaus Hartke wrote:
> "critical"/"elective" and "safe to forward without

That's at least what I thought so far. Does the "critical", "safe to
forward without understanding" combination not make sense or do we
just have no option that falls in this class at this time?

Klaus

---

From: Zach Shelby <[email-masked]>
Date: Mon, 11 Jun 2012 12:15:25 +0300

> - elective, safe to forward without understanding

I think you are right. So instead of a third class, we could just call this thing "Proxy-Safe" which is something an Option can be in addition to being Critical or Elective. 

An exercise that would help us thinking through this change. What existing options would be considered:

1. Critical and Proxy-Safe

2. Elective and Proxy-Safe

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
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: Klaus Hartke <[email-masked]>
Date: Mon, 11 Jun 2012 11:33:58 +0200

> 2. Elective and Proxy-Safe

Here's a quick compilation (not necessarily completely accurate):

+-------+--------+-----+----+--------+-------------+
|Request|Response|Cache|Safe|Critical|Name         |
+-------+--------+-----+----+--------+-------------+
|   -   |   X    |  -  | X  |    X   |Content-Type |
|   -   |   X    |  -  | -  |    -   |Max-Age      |
|   X   |   -    |  X  | -  |    X   |Proxy-Uri    |
|   X   |   X    |  X  | X  |    -   |ETag         |
|   X   |   -    |  X  | X  |    X   |Uri-*        |
|   -   |   X    |  -  | X  |    -   |Location-*   |
|   X   |   X    |  -  | -  |    -   |Observe      |
|   X   |   X    |  -  | -  |    X   |Token        |
|   X   |   -    |  X  | X  |    -   |Accept       |
|   X   |   -    |  X  | X  |    X   |If-Match     |
|   X   |   X    |  -  | X  |    -   |Vendor       |
|   X   |   X    |  -  | -  |    X   |Block2       |
|   X   |   X    |  -  | X  |    -   |Size         |
|   X   |   X    |  -  | -  |    X   |Block1       |
|   X   |   -    |  X  | X  |    X   |If-None-Match|
+-------+--------+-----+----+--------+-------------+

Klaus

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 11 Jun 2012 11:47:17 -0000

#241: Proxy Safe & Cache Key indication for options

#choose ticket.new
  #when True

    #end
    #if changes_descr

--
    #end
    #if change.comment

Comment(by zach@…):

    #end
  #end
#end

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/241#comment:2>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 11 Jun 2012 12:00:16 -0000

#choose ticket.new
  #when True

    #end
    #if changes_descr

--
    #end
    #if change.comment

Comment(by zach@…):

 Klaus pointed out that in addition to the proxy safe to forward, an
 indication of inclusion in the cache key would be needed. In addition, it
 was pointed out the this "Proxy Safe" indication is needed for both
 elective and critical options. This means we would have to deal with three
 pieces of information:

 * Critial / Elective
 * Proxy Safe
 * Cache Key

 We propose that these can be handled using the last 3 LSB bits of the
 option number (not the delta), where Critical/Elective is masked on the
 first LSB (as it is now), Proxy Safe on the second LSB (every other two
 options), and Cache Key on the third LSB (every other four options).

 On initial indication of which current options might be Proxy Safe or
 Cache Key was compiled by Klaus (needs to be double-checked):

 {{{
 }}}

 If we implement this ticket, it has two consequences:

 1. Most options numbers will be re-assigned to match the masks
 2. Ticket #230 (http://trac.tools.ietf.org/wg/core/trac/ticket/230) should
 be re-thought as with all Uri-* and Location-* options the new masks
 require option #s into the 50s. If the Uri and Location URIs would require
 a single option, we are only into the 20s as now. See a proposed solution
 in Ticket #230.
    #end
  #end
#end

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/241#comment:3>
core <http://tools.ietf.org/core/>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 11 Jun 2012 14:41:40 +0200

I think we need to discuss the meaningful combinations here.
For instance, for a critical, non-safe-to-be-forwarded-without-knowing-it option, it is simply not necessary to indicate in the option number whether it is a cache key or not (everybody handling this option knows that), so we are free to use the bit at will.
The cache key property is only relevant for requests, anyway?
I don't understand what "Cache" means for repeatable options (e.g., Accept).
We don't have a Cache-key/non-safe/elective combination.  Just luck?
I'm not sure I understand the difference between the bits of Uri* and *Uri.
It may be necessary to rip apart options where the request usage has different semantics from the response usage.
We may need vendor options for all meaningful combinations of bits.
I would prefer to have a set bit for "unsafe" instead of "safe" (if we have a bit for "critical" instead of "elective").

If we go this route, we probably should look at all options proposed so far (see the registry table in the SVN) and guess what combinations are how likely.  That will enable us to come up with a good encoding.

Grüße, Carsten

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 11 Jun 2012 13:26:07 -0000

#choose ticket.new
  #when True

    #end
    #if changes_descr

--
    #end
    #if change.comment

Comment(by zach@…):

 Comment from Carsten:

 I think we need to discuss the meaningful combinations here.
 For instance, for a critical, non-safe-to-be-forwarded-without-knowing-it
 option, it is simply not necessary to indicate in the option number
 whether it is a cache key or not (everybody handling this option knows
 that), so we are free to use the bit at will.
 The cache key property is only relevant for requests, anyway?
 I don't understand what "Cache" means for repeatable options (e.g.,
 Accept).
 We don't have a Cache-key/non-safe/elective combination.  Just luck?
 I'm not sure I understand the difference between the bits of Uri* and
 *Uri.
 It may be necessary to rip apart options where the request usage has
 different semantics from the response usage.
 We may need vendor options for all meaningful combinations of bits.
 I would prefer to have a set bit for "unsafe" instead of "safe" (if we
 have a bit for "critical" instead of "elective").

 If we go this route, we probably should look at all options proposed so
 far (see the registry table in the SVN) and guess what combinations are
 how likely.  That will enable us to come up with a good encoding.
    #end
  #end
#end

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/241#comment:4>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 25 Jun 2012 20:13:36 -0000

Changes (by hartke@…):

 * version:   => coap-09
 * milestone:   => post-WGLC-1

-- 
----------------------------------+--------------------------
 Reporter:  zach@…                |       Owner:  zach@…
     Type:  protocol enhancement  |      Status:  new
 Priority:  minor                 |   Milestone:  post-WGLC-1
Component:  coap                  |     Version:  coap-09
 Severity:  -                     |  Resolution:
 Keywords:                        |
----------------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/241#comment:5>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Wed, 27 Jun 2012 12:12:07 -0000

Comment (by esko.dijk@…):

 Maybe already indicated by Carsten above; but here goes:
 In my view there's no Safe/Unsafe bit needed in the encoding for critical
 options. An intermediary already has to understand all criticial options
 before processing a request, so it can have hardcoded knowledge which ones
 are Safe/Unsafe. No need to use encoding bits in that case.

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/241#comment:6>
core <http://tools.ietf.org/core/>