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

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

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

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