Subject: [core] #24: Clarification about repeated options

From: "core issue tracker" <[email-masked]>
Date: Tue, 24 Aug 2010 15:14:01 -0000

#24: Clarification about repeated options
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  zach@…            
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:  coap-02           
Component:  coap                |     Version:                    
 Severity:  -                   |    Keywords:                    
--------------------------------+-------------------------------------------
 coap-01 did not specify whether an option can appear multiple times in a
 CoAP header. It was pointed out in Maastricht that coap-02 should clearly
 either allow or forbid repeated options. This ticket is to decide whether
 we should allow (and have any real use for) repeated options in coap-02.

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

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 24 Aug 2010 21:02:45 +0200

>  we should allow (and have any real use for) repeated options in coap-02.

The only real use for repeated options so far is the inclusion of
multiple Etags in a GET request. IMO that's a good thing to have. If
we forbid repeated options, we need a format to store multiple byte
sequences in a single option, such as

     0
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-...-+-+-+
    |   x   |   y   | ...x bytes... | ...y bytes... | ... etc. ...
    +-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-...-+-+-+

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Aug 2010 22:56:18 +0200

We currently have just one example where allowing repeatable options is beneficial as it removes the need to define an array representation for the multivalued option value.

Even if we didn't, array-valued options are likely to come up later.  Saying they don't, appears to be a form of proof by lack of imagination.

As a general observation, nodes that do not implement such a repeatable option can ignore all option instances and thus do not need to implement the concept of repeatable options at all.
Nodes that do implement the repeatable option benefit from the simplified encoding.

The cognitive dissonance mainly seems to come from attempts at providing general option handling code that processes options independent of their semantics.

My take is therefore:
Do not explicitly disallow repeatable options, as there is no benefit in doing so.
Use them where and when they do provide a benefit.
Unless a specific option is specifically identified as repeatable (and the semantics of the resulting array of option values is defined), an option defined for CoAP is not repeatable, and repeating such an option in a request should lead to a 400 error.

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Wed, 25 Aug 2010 13:36:56 +0300

> Unless a specific option is specifically identified as repeatable (and the semantics of the resulting array of option values is defined), an option defined for CoAP is not repeatable, and repeating…

Works for me - would have no problem including text like this in coap-02. 

Zach

> 
> Gruesse, Carsten
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
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