[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

CoRE Working Group                                             C. Groves
Internet-Draft                                                   W. Yang
Intended status: Standards Track                                  Huawei
Expires: September 11, 2017                               March 10, 2017


                             SenML Options
                   draft-groves-core-senml-options-00

Abstract

   SenML [I-D.ietf-core-senml] defines an initial set of base and
   regular attributes which are tied to a particular version of SenML.
   SenML also allows the definition of additional attributes by
   extending the syntax with a new label.  Allowing the extension of
   attributes brings the problem of how do endpoints negotiate whether
   the new attribute can be used or not?  This document discusses the
   issue and proposes some potential solutions to this issue.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 11, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Groves & Yang          Expires September 11, 2017               [Page 1]


Internet-Draft                SenML Options                   March 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Solution space analysis . . . . . . . . . . . . . . . . . . .   3
     3.1.  Version Numbering . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Mandatory / Optional Indication . . . . . . . . . . . . .   4
     3.3.  Options Mechanism . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Media Type Definition and Parameters  . . . . . . . . . .   6
   4.  Solution Proposal . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Accept Media Type Parameter (AMTP) Option . . . . . . . .   9
     4.2.  Content-Format Media-Type Parameter Option  . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   8.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   SenML [I-D.ietf-core-senml] defines an initial set of base and
   regular attributes which are tied to a particular version of SenML.
   SenML also allows the definition of additional attributes by
   extending the defined syntax with a new label.  Allowing the
   extension of attributes brings the problem of how do endpoints
   negotiate whether the new attribute can be used or not?

   For example: A CoAP client issues a GET that indicates support of
   SenML through the use of an CoAP Accept option.  A CoAP server
   supports the SenML attributes defined in [I-D.ietf-core-senml] and in
   addition supports the Base Time Offset (BTO)
   [I-D.groves-core-senml-bto] attribute.  The server responds using the
   BTO attribute.












Groves & Yang          Expires September 11, 2017               [Page 2]


Internet-Draft                SenML Options                   March 2017


   [ {"bn": "urn:dev:ow:10e2073a01080063",
         "bt": 1320067464,
         "bto": 10,
         "bu": "%RH",
         "v": 21.2},
         { "v": 21.3},
         { "v": 21.4},
         { "v": 21.4},
         { "v": 21.5},
         { "v": 21.5},
         { "v": 21.5},
         { "v": 21.6},
         { "v": 21.7},
         { "v": 21.5},
      ...

           Figure 1: Response with SenML using base time offset

   As the CoAP client does not understand the "bto" attribute it will
   ignore the attribute.  This means that the time information is lost
   for each of the SenML records.  Whereas if the Server had not used
   "bto" the client would have been able to understand the information.

   This is mainly a problem when the server provides a response to a
   message (i.e.  GET) rather than when a client uses the SenML media
   type in a message (i.e.  PUT).  In this later case the client can
   modify its behaviour and not use an attribute based on an error
   response from the server.

   A solution is needed to prevent incompatible attributes from being
   used.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   See [I-D.ietf-core-senml] for further definitions.

3.  Solution space analysis

   The extension of protocols in a compatible manner is not a new
   problem.  Some approaches to handle the are discussed below.  The
   discussion below is not meant to be treatise on protocol extension
   but to highlight potential solutions.




Groves & Yang          Expires September 11, 2017               [Page 3]


Internet-Draft                SenML Options                   March 2017


3.1.  Version Numbering

   A version number is used to indicate when changes have been made to a
   syntax.  In some protocols a major version is used to indicate non-
   backward compatible changes and a minor version is used to indicate
   backwards compatible changes.  SenML does use a version number
   however it is an integer (no major and minor).  It is used to
   indicate the version number of the media type format.  The version
   does not appear in the media type format name.  However presumably
   the proposed registrations (e.g. senml+json) imply the use of version
   number 10 (see sect.4.1/[I-D.ietf-core-senml]).  If in the future
   there is a new version how does the endpoint negotiate which SenML
   version to use?  A simple solution would be to create a new media
   type name incorporating the new version e.g. "senml_v11+json".  A
   CoAP endpoint could then use an Accept option to indicate support for
   "senml+json" and/or "senml_v11+json".

   This method does generally mean that for each new attribute and
   version the endpoints must at least understand all previously defined
   attributes.  Although major versions in some protocols do not
   maintain backwards compatibility.

   SenML does indicate that for certain representations i.e. EXI
   representation (application/senml+exi) that the schemaID number must
   be updated when the syntax is updated for a new attribute.  This is
   effectively a version mechanism but the other representation formats
   do not follow this approach.

   However the current SenML draft does allow the definition of
   additional attributes without increasing the SenML version number.
   Indeed there is a trend at the IETF that protocol versions change
   very rarely.  Instead updates are incorporated via option or
   extension mechanisms.

   Therefore it seems that an approach of utilising a version number for
   each additional new attribute does not seem appropriate for SenML.

3.2.  Mandatory / Optional Indication

   Some protocols use a mechanism to indicate whether a parameter is
   mandatory or optional to understand.  This is based on the assumption
   that a sending endpoint knows the functions that a parameter/s relate
   to and can indicate whether the receiving endpoint must understand
   the parameter/s to implement the function.  A receiving endpoint will
   anaylse the received parameters and if it does not understand the
   parameter it will check the mandatory/option tag to see what it
   should do.  If the parameter is marked as mandatory then the
   receiving endpoint will generate an error.  If the parameter is



Groves & Yang          Expires September 11, 2017               [Page 4]


Internet-Draft                SenML Options                   March 2017


   marked as optional then the receiving endpoint will continue
   processing in knowledge that it doesn't need the parameter.

   CoAP uses a mechanism similar to this for Options.  By looking at the
   option number an endpoint can determine whether it is critical or
   not.

   SenML does indicate that the version indicates the mandatory to
   understand attributes (sect. 4.3/[I-D.ietf-core-senml]).  SenML also
   indicates that some attributes (i.e. base attributes) are optional
   but this is in context of "optional to be used" rather than "optional
   to be understood".

   Whilst a method could be defined to indicate in SenML whether an
   attribute is mandatory or optional, its not clear that it would be
   useful.  Given the number of use cases where CoAP can be used a
   server may not know which information in a SenML pack is relevant for
   a client.  E.g.  Whilst a server may return time information
   associated with a record it doesn't actually know whether it is
   useful to the client.  The usefulness is application specific to the
   client.

   Therefore it seems this approach is also not appropriate for SenML.

3.3.  Options Mechanism

   Some protocols allow the optional parts of the protocol to be
   negotiated during the initial protocol negotiation.  For example the
   SIP protocol has the OPTIONS method [RFC3261].  The CLUE protocol
   [I-D.ietf-clue-protocol] also defines an extension method where an
   OPTIONS message is used to negotiate the protocol extensions.  The
   benefits of such an approach is that two endpoints can negotiate
   which extensions they will use in a session ensuring compatible
   communications.

   However these approaches assume an application level session where
   there are establishment, communication and release phases.  SenML is
   a media type format primarly defined to be used with the HTTP and
   CoAP protocols.  These protocols don't follow a session based
   approach.

   HTTP/1.1 does have the OPTIONS method [RFC2616] however the use is
   largely undocumented.  CoAP does not have an equivalent method.

   CoAP does have a method for negotiating signalling through "Signaling
   Option Numbers" (sect.4.2/[I-D.ietf-core-coap-tcp-tls]).  This
   however is more used to negotiate the properties of the signalling




Groves & Yang          Expires September 11, 2017               [Page 5]


Internet-Draft                SenML Options                   March 2017


   connection than any elements of the CoAP payload (not withstanding
   the Blockwise transfer).

   CoAP does have the OPTIONs mechanism allowing for the definition of
   optionality functionality associated with a CoAP message.  It also
   defines the concept of critical and elective options.  Two options
   related to Content-type/Content-format are "Content-Format" and
   "Accept".  These options allow endpoints to indicate the media types
   are using or wish to use.  HTTP also uses these options.

   CoAP also allows a per message exchange of what is supported for a
   particular resource.  This seems more appropriate than a protocol
   level negotiation of the support of SenML attributes.

   This functionality is very close to what needs to be acheived for
   negotiating SenML attributes.

3.4.  Media Type Definition and Parameters

   Potentially the media type name could be used to indicate versions or
   extensions.  This may be appropriate where there are seldom changes
   that affect the whole media type.  However it may become unwieldy if
   the media type name is used to define combinations of SenML
   attributes, e.g. given 3 extensions a, b and c you could end up with
   media names / content formats for a, b, c, a+b, a+c, b+c, a+b+c.  The
   problem gets worse each time an extension is added.  It is made even
   worse because Table 7/[I-D.ietf-core-senml] defines 8 different
   content formats for SenML that would need to be updated.  To allow
   combinations of these parameters on the media types defined in SenML
   it would need 56 Content-format code points.  The content format
   range 0..255 for IETF specifications isn't particularly large.

   [RFC6838] allows for the registration of media type parameters.  This
   allows further companion information to be included along with the
   media type.  Charset is a common parameter (See [RFC3023]).  This
   information could be used to provide version or option information
   associated with a media type.

   This appears to be a good solution to indicate if additional SenML
   attributes are supported in a media type.  Whilst HTTP supports media
   type parameters, CoAP does not support media type parameters or
   extensions (i.e. see sect.10.2.2/[RFC7252]).  Meaning that parameters
   cannot be used as a common approach for HTTP and CoAP.  However this
   solution is used in section 16.9.1/[I-D.ietf-cose-msg] which takes
   the approach of defining an optional parameter for the "application/
   cose".  It then assigns multiple CoAP Content-Formats for the values
   associated with the optional parameter (see
   sect.16.10/[I-D.ietf-cose-msg]).



Groves & Yang          Expires September 11, 2017               [Page 6]


Internet-Draft                SenML Options                   March 2017


4.  Solution Proposal

   There doesn't appear to be one outstanding approach for negotiating
   SenML attributes common to both HTTP and CoAP.  The authors believe
   that a hybrid approach as per [I-D.ietf-cose-msg] is needed in order
   to be able to negotiate which SenML extension attributes are used.

   The first part would be the definition of a optional media-type
   parameter that allows an endpoint utilising HTTP to indicate the
   SenML extension attributes that it is using or accepts.  This could
   be in the form of a comma separated string list of SenML labels from
   those registered in the SenML label registry.  Only attributes NOT
   defined in [I-D.ietf-core-senml] would be allowed.

   e.g.  Content-type: application/senml+json; ext=abc,xyz

   In order to allow this functionality in the base version of SenML an
   optional parameter would be needed in the media type registrations in
   sect.11.3/[I-D.ietf-core-senml].

   i.e.  o Optional parameter: SenML extensions

   This parameter indicates which SenML extensions are associated with
   the media type.  The parameter is defined by the following ABNF:

       SenML-ext = "ext" "=" <"> senml-label *("," senml-label) <">
       ; Note: this follows the {{RFC2616}} quoted-string form.
       ; senml-label is the label string from the list of IANA
       ; registered SenML labels.
       ; Only non-{{I-D.ietf-core-senml}} labels are allowed.

   For example: ext="a,b,c";

   If the group decides that there will only ever be a small number of
   SenML extensions then the simplest approach would be to follow
   [I-D.ietf-cose-msg] and define multiple CoAP content formats
   associated with potential extensions.  This would be done in which
   ever document defines the SenML extension.  For example
   [I-D.groves-core-senml-bto] would add the following to the IANA
   considerations section:











Groves & Yang          Expires September 11, 2017               [Page 7]


Internet-Draft                SenML Options                   March 2017


    +------------------------------------+----------+-----+-----------+
    | Media Type                         | Encoding | ID  | Reference |
    +------------------------------------+----------+-----+-----------+
    | application/senml+json; ext="bto"  |          | TBD | TBD       |
    |                                    |          |     |           |
    | application/sensml+json; ext="bto" |          | TBD | TBD       |
    |                                    |          |     |           |
    | application/senml+cbor; ext="bto"  |          | TBD | TBD       |
    |                                    |          |     |           |
    | application/sensml+cbor; ext="bto" |          | TBD | TBD       |
    |                                    |          |     |           |
    | application/senml+xml; ext="bto"   |          | TBD | TBD       |
    |                                    |          |     |           |
    | application/sensml+xml; ext="bto"  |          | TBD | TBD       |
    |                                    |          |     |           |
    | application/senml+exi; ext="bto"   |          | TBD | TBD       |
    |                                    |          |     |           |
    | application/sensml+exi; ext="bto"  |          | TBD | TBD       |
    +------------------------------------+----------+-----+-----------+

                     Table 1: New CoAP content formats

   Text would also need to be added to [I-D.ietf-core-senml] to describe
   the procedure for support of the media type parameter in CoAP.

   If issuing potentially a large number of content-format numbers is
   problematic a separate approach could be taken.  A new CoAP option
   could be defined to allow media-type parameters to be carried in CoAP
   messages when then Content-Format or Accept options are used.  As the
   Content-Format and Accept options may be used in the same request
   (with two different media types) two new options would be required,
   one for the media-type parameters associated with the Content-Format
   Option and one for the media-type parameters associated with the
   Accept option.

   *Editor's note: Alternatives could include defining the option for
   both CoAP and HTTP.  However this would likely mean that the option
   would become specific to SenML extensions rather than a general
   mechanism for carrying media type parameters.*

   As CoAP only allows a single Content-Format to be carried in the
   Content-Format and Accept options it would be straight forward to
   define an option that allows media-type parameters to be carried.
   One complication is that the encoding and syntax of the media-type
   parameters is up to the media-type definition.  It could be a string,
   integer, binary, etc.  Therefore the option value would need to be an
   opaque sequence of bytes.  If the scope was limited to SenML then the
   option format would be a narrowed to a string of labels.



Groves & Yang          Expires September 11, 2017               [Page 8]


Internet-Draft                SenML Options                   March 2017


   As multiple parameters could be defined for a media-type the
   mechanism must allow multiple media type parameter to be signalled in
   a CLUE message.  One possible method is to define the option value
   syntax to allow multiple parameter to be specified as a single
   parameter value.  Alternatively multiple instances of the option
   could be used in the CoAP message.  This method is indicated in the
   IANA registration by allowing the option multiple times.

   If a new generic option is defined it's not clear that
   [I-D.ietf-core-senml] would be the best place to define the option.
   If the scope is limited then [I-D.ietf-core-senml] would be
   appropriate.  Whichever draft defines the options it would need to
   define them for registration with IANA along the lines of:

                      +--------+-------+-----------+
                      | Number | Name  | Reference |
                      +--------+-------+-----------+
                      | TBD    | AMTP  | TBD       |
                      |        |       |           |
                      | TBD    | CFMTP | TBD       |
                      +--------+-------+-----------+

                     Table 2: New CoAP Option Numbers

4.1.  Accept Media Type Parameter (AMTP) Option

   o The meaning of the option in a request: It indicates the media-type
   parameters associated with the content-format (media-type) specified
   in the Accept option.

   Note: Some content-formats contain media-type parameters as part of
   the content-format ID registrations.  The AMTP option SHALL not be
   used with these CoAP content-formats.

   o The meaning of the option in a response: Not used.

   o Whether the option is critical or elective: Critical as per the
   Accept option.

   o Whether the option is Safe-to-Forward: Safe as per the Accept
   option.

   Note: Potentially it could be unsafe to forward an opaque byte
   sequence that the proxy does not understand.  However processing this
   option should only be done within the context of the media-type
   specified by the Accept option.





Groves & Yang          Expires September 11, 2017               [Page 9]


Internet-Draft                SenML Options                   March 2017


   o The format and length of the option's value: A variable length
   opaque sequence of bytes.  The encoding of the bytes is defined as
   per the syntax for the parameters in the media-type definition
   document.

   o Whether the option must occur at most once or whether it can occur
   multiple times: Multiple times.  Each instance containing a seperate
   media-type parameter.  Whether the option can be included multiple
   times for the one media type parameter is dependent on whether the
   media-type definition allows for multiple instances of the one media
   type parameter.

   o Default value: None unless the media-type indicated in the accept
   option defines a default parameter/s value.

4.2.  Content-Format Media-Type Parameter Option

   o The meaning of the option in a request: When used together with the
   Content-Format option it indicates the media-type parameters
   associated with the content-format (media-type) specified in the
   content-format option.

   Note: Some content-formats contain media-type parameters as part of
   the content-format ID registrations.  The CFMTP option SHALL not be
   used with these CoAP content-formats.

   o The meaning of the option in a response: When used together with
   the Content-Format option it indicates the media-type parameters
   associated with the content-format (media-type) specified in the
   content-format option.

   o Whether the option is critical or elective: As per the Content-
   Format option it is elective.

   o Whether the option is Safe-to-Forward: Safe as per the Content-
   format option.

   Note: Potentially it could be unsafe to forward an opaque byte
   sequence that the proxy does not understand.  However processing this
   option should only be done within the context of the media-type
   specified by the Content-Format options.

   o The format and length of the option's value: A variable length
   opaque sequence of bytes.  The encoding of the bytes is defined as
   per the syntax for the parameters in the media-type definition
   document.





Groves & Yang          Expires September 11, 2017              [Page 10]


Internet-Draft                SenML Options                   March 2017


   o Whether the option must occur at most once or whether it can occur
   multiple times: Multiple times.  Each instance containing a seperate
   media-type parameter.  Whether the option can be included multiple
   times for the one media type parameter is dependent on whether the
   media-type definition allows for multiple instances of the one media
   type parameter.

   o Default value: None unless the media-type indicated in the content-
   format option defines a default parameter/s value.

5.  Security Considerations

   SenML security issues are described in [I-D.ietf-core-senml].  Some
   extra considerations are indicated above.

6.  IANA Considerations

   Section 4 discusses potential IANA registrations.

7.  Acknowledgements

   TBD

8.  Changelog

   TBD

9.  References

9.1.  Normative References

   [I-D.groves-core-senml-bto]
              Groves, C. and W. Yang, "SenML Base Time Offset
              Attribute", draft-groves-core-senml-bto-00 (work in
              progress), October 2016.

   [I-D.ietf-core-senml]
              Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
              Bormann, "Media Types for Sensor Measurement Lists
              (SenML)", draft-ietf-core-senml-04 (work in progress),
              October 2016.

   [I-D.ietf-cose-msg]
              Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              draft-ietf-cose-msg-24 (work in progress), November 2016.






Groves & Yang          Expires September 11, 2017              [Page 11]


Internet-Draft                SenML Options                   March 2017


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616,
              DOI 10.17487/RFC2616, June 1999,
              <http://www.rfc-editor.org/info/rfc2616>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <http://www.rfc-editor.org/info/rfc6838>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

9.2.  Informative References

   [I-D.ietf-clue-protocol]
              Presta, R. and S. Romano, "CLUE protocol", draft-ietf-
              clue-protocol-13 (work in progress), February 2017.

   [I-D.ietf-core-coap-tcp-tls]
              Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              draft-ietf-core-coap-tcp-tls-07 (work in progress), March
              2017.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, DOI 10.17487/RFC3023, January 2001,
              <http://www.rfc-editor.org/info/rfc3023>.








Groves & Yang          Expires September 11, 2017              [Page 12]


Internet-Draft                SenML Options                   March 2017


Authors' Addresses

   Christian Groves
   Huawei
   Australia

   Email: Christian.Groves@mail01.huawei.com


   Weiwei Yang
   Huawei
   P.R.China

   Email: tommy@huawei.com





































Groves & Yang          Expires September 11, 2017              [Page 13]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/