ietf-rats-wg / draft-eat-mt Goto Github PK

DEB has been dropped in favour of BUNDLE, see ietf-rats-wg/eat#252

We need to take care of the fallout.

This doc refers to both "profile" and "eat_profile". EAT itself uses both terms, the first for the CBOR claim and the second for the JSON claim (because "profile" is already registered in JWT).

I think we either need to fix EAT so it just uses "eat_profile", or explain the mixing of terms in this document.

Nancy's note on adoption:

Discussion on the use cases and rationale for this construction
should be noted to address Anders’ comments as well.

See https://mailarchive.ietf.org/arch/msg/rats/JKGJoRWpDwSRTW5OXBYSG1sm6Lk/

draft-fossati-rats-eat-media-type.md

:-)

Dave T's note:

Separately, for use in HTTP, see RFC 9205's discussion of media types.
This was recently published by the HTTPbis working group. It's possible
(I don't know) that it could be a useful Informative reference from the
eat-media-type draft.

Dave Thaler in https://mailarchive.ietf.org/arch/msg/rats/5BZdOsNNquo9l6nuUSEbkobOWiY/

I have just one wording suggestion.  In section 3 it says:

> The media types defined in this document include an optional profile
> parameter that can be used to mirror the eat_profile claim of the
> transported EAT.  Exposing the EAT profile at the API layer allows
> API routers to dispatch payloads directly to the profile-specific
> processor without having to snoop into the request bodies. 
 
That is of course true, but the justification can be even stronger by pointing out that it also allows use when the payload is not present in the message, such as in an Accept header (and indeed section 4 shows that).  
 
Indeed, the TEEP protocol uses it in both Content-Type and Accept, just like in section 4.

Conditions for requesting early allocation -- see also §2 of RFC7120:

• The code points must be from a space designated as "RFC Required", "IETF Review", or "Standards Action". Additionally, requests for early assignment of code points from a "Specification Required" registry are allowed if the specification will be published as an RFC.

Per Section 3.1 of [RFC6838], Standards Tree requests made through IETF documents will be reviewed and approved by the IESG.

• The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft.

draft-ietf-rats-eat-media-type is that Internet-Draft

• The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable.

we think they are stable

• The Working Group chairs and Area Directors (ADs) judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment, or that failure to make an early allocation might lead to contention for the code point in the field.

this we should ask

We need a way to pass the profile information when using content formats.

A new CoAP option would seem like the natural way to do this.

A generally useful thing could be an option that carries any media type parameters (including profile).

The first simple and obvious question is what would the type of a UCCS be? There is also the DEB. https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-12#section-5

If this is to parallel COSE, then I think we'd have:

eat-cwt (eat-cwt+cbor seems redundant; or maybe eat+cbor implies CWT)
eat-jwt (eat-jwt+json seems redundant)
eat-deb+cbor
eat-deb+json
eat-uccs (eat-uccs+cbor seems redundant)
eat-ujcs (eat-ujcs+json seems redundant)

They all follow the EAT semantics and requirements, but they are different forms and encodings.

Not sure how the section number references work here but the EAT-13 draft has significantly different section numbers than -12 and this doc refers to -12 sections.