one more reason for defining a profile parameter

[thomas-fossati]

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.

[thomas-fossati]

Also, @carl-wallace on the same thread:

It may be worth adding an informational reference to RFC4151 for the tag URIs in the
examples. Maybe add this to the sentence at the end of section 4:
 
“In both cases, a tag URI [RFC4151] identifying the profile is carried as an explicit
parameter.”