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

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

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

    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:
    > 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
    Yes.
    > 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".)
    
    Yes, something like that.
    
    Best Regards,
    
    Alexey
    
    >
    > 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
    >      
    >