TEEP Server must support all message formats in Single API?

[ko-isobe]

I'm trying to develop TEEP server as prototyping.
Based on recent IETF Hackathon, my proto server supports JOSE,
but I think the TEEP server should support CBOR in the future.
So my TEEP server implementation is going to support both message formats, JOSE and CBOR.

My question is whether TEEP server must support both media types in a single API or not.
(Content-type is thought to be useful for distinguishing these message formats.)
TEEP server must support JOSE and/or CBOR at one API?

[dthaler]

TEEP protocol was updated to just use CBOR, same change is now in the transport spec (in GitHub, not yet published as an I-D)

[mcd500]

This is feedback from the virtual hackathon last week.

It is some what related to this topic.
There are situations that the Client App in the Device would like to inform the TAM whether it would like to Install or Delete TA in the Device.
Then the TAM could react accordingly for the query response.

In the draft the url is constant string of /tam. Would it be good to use it to send the wish of the device as /tam_install and tam_delete, or some thing similar?
The alternative is probably adding install or delete information in the teep protocol, but it will be more larger changes than using url.

[dthaler]

@mcd500 I think that should done in the TEEP protocol not in the transport. That's because I believe it needs to be secured and the transport is not considered secure because it typically terminates and originates in the REE.

[mcd500]

@dthaler The install or delete information in unsecured header is not good, I will move this topic to teep protocol. Thanks,

[dthaler]

From interim minutes:
https://www.ietf.org/proceedings/interim-2020-teep-02/minutes/minutes-interim-2020-teep-02-202004060730-00

a)Close#8 in git