Subject: Re: [media-types] Media-type registrations for senml-etch+json and senml-etch+cbor

From: Alexey Melnikov <[email-masked]>
Date: Wed, 7 Aug 2019 19:52:02 +0100

Hi Carsten/editors,

I've made a couple of comments on this document verbally, but I never 
put them in email. My comments below:

On 12/07/2019 12:12, Carsten Bormann wrote:

> »The Sensor Measurement Lists (SenML) media type and data model can
> be used to send collections of resources, such as batches of sensor
> data or configuration parameters.  The existing media types
> (defined in RFC 8428) are useful for the traditional operations
> GET, PUT, POST.  The CoAP iPATCH, PATCH, and FETCH methods enable
> accessing and updating parts of a resource or multiple resources
> with one request.  For using these methods to access and operate on
> resources represented with the SenML data model, the present
> document defines variants of the SenML media types, for JSON and
> CBOR representations only.«
>
> Please review the media-type registrations as proposed in
> draft-ietf-core-senml-etch-04, copied below (RFC-AAAA is the
> RFC-to-be from that).
>
> Grüße, Carsten
>
>
>
>
>
> 5.2.  senml-etch+json Media Type
>
>     Type name: application
>
>     Subtype name: senml-etch+json
>
>     Required parameters: none
>
>     Optional parameters: none
>
>     Encoding considerations: Must be encoded as using a subset of the
>     encoding allowed in [RFC8259].  This simplifies implementation of a
>     very simple system and does not impose any significant limitations as
>     all this data is meant for machine to machine communications and is
>     not meant to be human readable.
While this test is useful, it is not what this field is all about. You 
need to pick one of 7bit, 8bit, binary or framed. See 
<https://tools.ietf.org/html/rfc6838#section-4.8>
>
>     Security considerations: See Section 4 of RFC-AAAA.
>
>
>
>
>
> Keranen & Mohajer        Expires January 9, 2020                [Page 6]
> Internet-Draft          FETCH & PATCH with SenML               July 2019
>
>
>     Interoperability considerations: Applications MUST ignore any key
>     value pairs that they do not understand unless the key ends with the
>     '_' character in which case an error MUST be generated.  This allows
>     backwards compatible extensions to this specification.
>
>     Published specification: RFC-AAAA
>
>     Applications that use this media type: Applications that use the
>     SenML media type for resource representation.
>
>     Fragment identifier considerations: N/A
As this registration is using +json suffix, it should use text about 
Fragment identifiers as described in +json suffix registration. (You can 
find it on IANA's website)
>     Additional information:
>
>     Magic number(s): none
>
>     File extension(s): senml-etchj
>
>     Windows Clipboard Name: "SenML FETCH/PATCH format"
>
>     Macintosh file type code(s): none
>
>     Macintosh Universal Type Identifier code: org.ietf.senml-etch-json
>     conforms to public.text
>
>     Person & email address to contact for further information: Ari
>     Keranen [email-masked]
>
>     Intended usage: COMMON
>
>     Restrictions on usage: None
>
>     Author: Ari Keranen [email-masked]
>
>     Change controller: IESG
>
> 5.3.  senml-etch+cbor Media Type
>
>     Type name: application
>
>     Subtype name: senml-etch+cbor
>
>     Required parameters: none
>
>     Optional parameters: none
>
>     Encoding considerations: Must be encoded as using [RFC7049].
As above.
>
>
>
>
> Keranen & Mohajer        Expires January 9, 2020                [Page 7]
> Internet-Draft          FETCH & PATCH with SenML               July 2019
>
>
>     Security considerations: See Section 4 of RFC-AAAA.
>
>     Interoperability considerations: Applications MUST ignore any key
>     value pairs that they do not understand unless the key ends with the
>     '_' character in which case an error MUST be generated.  This allows
>     backwards compatible extensions to this specification.
>
>     Published specification: RFC-AAAA
>
>     Applications that use this media type: Applications that use the
>     SenML media type for resource representation.
>
>     Fragment identifier considerations: N/A
As above (Similar for +cbor suffix).
>
>     Additional information:
>
>     Magic number(s): none
>
>     File extension(s): senml-etchc
>
>     Macintosh file type code(s): none
>
>     Macintosh Universal Type Identifier code: org.ietf.senml-etch-cbor
>     conforms to public.data
>
>     Person & email address to contact for further information: Ari
>     Keranen [email-masked]
>
>     Intended usage: COMMON
>
>     Restrictions on usage: None
>
>     Author: Ari Keranen [email-masked]
>
>     Change controller: IESG
>
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types

---

From: Ari Keränen <[email-masked]>
Date: Wed, 7 Aug 2019 19:24:20 +0000

Thank you Alexey!

Regarding encoding, we re-used the text from the SenML RFC (https://tools.ietf.org/html/rfc8428#section-12.3.1). But simply changing this to "binary" as in RFC8259 works well for me too. I made a small PR for this:
https://github.com/core-wg/senml-etch/pull/7/files

Regarding the fragment ID considerations, do you mean we should copy the text for +cbor and +json from here:
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml

As in:
> The syntax and semantics of fragment identifiers specified for senml-etch+json SHOULD be as specified for "application/json". (At publication of this document, there is no fragment identification syntax defined for "application/json".)

and:
> The syntax and semantics of fragment identifiers specified for senml-etch+cbor SHOULD be as specified for "application/cbor". (At publication of this document, there is no fragment identification syntax defined for "application/cbor".)

Cheers,
Ari

On 07/08/2019, 21.52, "Alexey Melnikov" <[email-masked]> wrote:

    Hi Carsten/editors,

    
    As above.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 7 Aug 2019 20:29:42 +0100

Hi Ari,

On 07/08/2019 20:24, Ari Keränen wrote:

> Thank you Alexey!
>
> Regarding encoding, we re-used the text from the SenML RFC (https://tools.ietf.org/html/rfc8428#section-12.3.1).
I missed it earlier :-)!
>   But simply changing this to "binary" as in RFC8259 works well for me too. I made a small PR for this:
Yes.
>> The syntax and semantics of fragment identifiers specified for senml-etch+cbor SHOULD be as specified for "application/cbor". (At publication of this document, there is no fragment identification…

Yes, something like that.

Best Regards,

Alexey

---

From: Ari Keränen <[email-masked]>
Date: Wed, 7 Aug 2019 19:42:58 +0000

Thanks for the quick reply Alexey! I fixed this now in the same PR: 
https://github.com/core-wg/senml-etch/pull/7/files

I'll give everyone here a few days to comment and I can submit a new version on Friday if there are no further comments.

Cheers,
Ari

P.S. Apologies for top-posting and not using proper quoting. I have to use a challenged email client at the moment.

On 07/08/2019, 22.30, "Alexey Melnikov" <[email-masked]> wrote:

    Hi Ari,

    I missed it earlier :-)!
    Yes.

    Best Regards,
    
    Alexey

---

From: Ari Keränen <[email-masked]>
Date: Sat, 17 Aug 2019 08:22:01 +0000

Hi Alexey,

After looking into this in more detail, we realized that it actually makes sense to support the same fragment ID method with the Fetch/Patch Records as with regular SenML records. I created a new PR based on this (also includes the encoding fix from the other PR):
https://github.com/core-wg/senml-etch/pull/8/files

I'll submit a new draft version based on this.

Cheers,
Ari

On 07/08/2019, 22.42, "Ari Keränen" <[email-masked]> wrote:

    Cheers,
    Ari

    
        Hi Ari,

        I missed it earlier :-)!
        Yes.

        Best Regards,
        
        Alexey