Subject: Re: [Teep] Call for adoption of draft-thaler-teep-otrp-over-http

From: Mingliang Pei <[email-masked]>
Date: Wed, 12 Jun 2019 19:31:00 +0000

Sorry for late catch up on email thread. I think we need to support CBOR too, and favor to add it as a subsequent separate draft. I also endorse the adoption of the transport draft.

Thanks,

Ming

On 5/29/19, 11:40 AM, "TEEP on behalf of Anders Rundgren" <[email-masked] on behalf of [email-masked]> wrote:

    Hi David,
    Since you mention the unfinished architecture document, have you seen https://clicktime.symantec.com/3TQuntRi95xtHKDzR9VRWN97Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F52%23issuecomment-493652265 ?
    
    This is about creating a *unified* (JSON/CBOR independent) TEE management API.
    
    Ten years ago I had something similar to OTrP but felt it was becoming "clunky" and limiting, so I threw it out and haven't regretted it a second.
    The switch wasn't that difficult after getting the core mechanics in place.
    Much later when I was forced switching protocol format from XML to JSON, *not a single bit* changed in the API.
    
    Regards,
    Anders

    On 2019-05-29 16:43, Wheeler, David M wrote:
    > I am more in favor of a CBOR/CWT binding than JSON, although I agree that JSON and JWT is more commonly deployed at the moment.
    > 
    > The direction I think we should push this is toward CBOR. However, I think that it is fine to build JSON into the OTrP protocol spec and then have an alternative specification that provides CBOR bindings – I would be willing to work with Anders on a such a specification (after the arch document is complete 😉 ).
    > 
    > Thanks,
    > 
    > Dave Wheeler
    > 
    > *From:* TEEP <[email-masked]> *On Behalf Of *Hannes Tschofenig
    > *Sent:* Wednesday, May 29, 2019 7:35 AM
    > *To:* Dave Thaler <dthaler=[email-masked]>; Anders Rundgren <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; [email-masked]
    > *Subject:* Re: [Teep] Call for adoption of draft-thaler-teep-otrp-over-http
    > 
    >   * The IoT market has adopted CBOR rather than JSON.
    > 
    >   * That’s a bit overstated, “IoT” is very broad and hence there are _/many/_ IoT “markets”, and many of them have not adopted CBOR. For example, if you look in industrial IoT, the dominant protocol is OPC UA, which uses neither CBOR nor JSON. In consumer IoT like in devices on shelves now, I think you will find that JSON is far more deployed than CBOR is (e.g., Hue light bulbs and many other IoT devices use JSON-over-HTTP). It is true that /some/ of the IoT market has adopted CBOR.  For example, OCF adopted CBOR, but OCF has very little actual deployment today.
    > 
    > I agree with Dave here. I think it is fair to say that the JWT has been implement and deployed by the Web community. Particularly in the OAuth context it is widely deployed.
    > 
    > CBOR has been suggested for IoT-related specifications but CBOR, COSE and CWT is definitely not widely implement and even less widely used.
    > 
    > The question I wonder is whether the current deployment status matters in our case and I don’t think it has any relationship to the call for adoption of draft-thaler-teep-otrp-over-http.
    > 
    > When the initial version of OTrP was written there was the assumption that the encoding of the protocol in JSON would be more convenient for Web developers given that the main deployment use case was for mobile phones and tablets.
    > 
    > Now, there is of course the question whether Web developers should be exposed to the details and the encoding of the OTrP protocol itself. I think that’s an important question. Afterall, we are trying to make the life of developers simpler with this work.
    > 
    > Since the formation of the TEEP group we have also added other use cases extending our original goals for OTrP. This makes me believe that it is worthwhile to look into a CBOR-based encoding as well. I also would like to take advance of ongoing working work in SUIT & RATS.
    > 
    > Ciao
    > Hannes
    > 
    > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
    > 
    
    _______________________________________________
    TEEP mailing list
    [email-masked]
    https://clicktime.symantec.com/396boPiov2Q8ZKx1VAUMjMh7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep

---

From: Dave Thaler <[email-masked]>
Date: Wed, 12 Jun 2019 21:42:30 +0000

JSON vs CBOR (or anything else) should not affect the transport draft as currently specified.  The transport just carries a generic payload and feeds it into the Agent as an opaque buffer.
The broker has no visibility into the encoding, it just transports raw payloads.  Only the OTrP implementation knows whether it's JSON or CBOR or whatever, so in my view that's a discussion
on the OTrP spec not the otrp-over-http spec.

Dave

-----Original Message-----
From: Mingliang Pei <Mingliang_Pei=[email-masked]> 
Sent: Wednesday, June 12, 2019 12:31 PM
To: Anders Rundgren <[email-masked]>; Wheeler, David M <[email-masked]>; Hannes Tschofenig <[email-masked]>; Dave Thaler <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; [email-masked]
Subject: Re: [Teep] Call for adoption of draft-thaler-teep-otrp-over-http

Thanks,

Ming

    Hi David,
    Since you mention the unfinished architecture document, have you seen https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F52%23issuecomment-493652265&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C6e15170aecc640e93c7508d6ef6c85b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636959646713484101&amp;sdata=mRuPRP7F%2Fv8s6F2eSbsA8V%2F4NycbmK4U3Xn7rIedpKE%3D&amp;reserved=0 ?

    
    Regards,
    Anders

    _______________________________________________
    TEEP mailing list
    [email-masked]
    https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C6e15170aecc640e93c7508d6ef6c85b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636959646713494087&amp;sdata=TiFDthL%2BxRuHOHfHH9hbed6mmLfKG8I5E6sdo4Tuu5M%3D&amp;reserved=0

---

From: Mingliang Pei <[email-masked]>
Date: Wed, 12 Jun 2019 21:59:16 +0000

Agreed, Dave, thanks, Ming

On 6/12/19, 2:42 PM, "Dave Thaler" <dthaler=[email-masked]> wrote:

    Dave
    
    -----Original Message-----
    From: Mingliang Pei <Mingliang_Pei=[email-masked]> 
    Sent: Wednesday, June 12, 2019 12:31 PM
    To: Anders Rundgren <[email-masked]>; Wheeler, David M <[email-masked]>; Hannes Tschofenig <[email-masked]>; Dave Thaler <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; [email-masked]
    Subject: Re: [Teep] Call for adoption of draft-thaler-teep-otrp-over-http

    Thanks,
    
    Ming

        Hi David,
        Since you mention the unfinished architecture document, have you seen https://clicktime.symantec.com/3SuxTt9iJ9KUAHy9YKwWpAq7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F52%2523issuecomment-493652265%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257C6e15170aecc640e93c7508d6ef6c85b8%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C636959646713484101%26sdata%3DmRuPRP7F%252Fv8s6F2eSbsA8V%252F4NycbmK4U3Xn7rIedpKE%253D%26reserved%3D0 ?

        
        Regards,
        Anders

        _______________________________________________
        TEEP mailing list
        [email-masked]
        https://clicktime.symantec.com/39GgxxuNwUX4UT6LXHifmoH7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteep%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257C6e15170aecc640e93c7508d6ef6c85b8%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C636959646713494087%26sdata%3DTiFDthL%252BxRuHOHfHH9hbed6mmLfKG8I5E6sdo4Tuu5M%253D%26reserved%3D0