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

[Ari Keränen <[e-mail]>]

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" <[e-mail]> wrote:

    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 [e-mail]
    >
    >     Intended usage: COMMON
    >
    >     Restrictions on usage: None
    >
    >     Author: Ari Keranen [e-mail]
    >
    >     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 [e-mail]
    >
    >     Intended usage: COMMON
    >
    >     Restrictions on usage: None
    >
    >     Author: Ari Keranen [e-mail]
    >
    >     Change controller: IESG
    >
    > _______________________________________________
    > media-types mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/media-types