Clarify meaning of missing datacontentype.

[alanconway]

Clarify the meaning of missing datacontentype, when it is allowed, and what that means when translating events between formats/protocols.

Also replaced "transport" with "protocol" everywhere, I believe that is now the preferred term. "Transport" is not defined in the terminology.

Fixes #520

[deissnerk]

LGTM
This definitely simplifies the handling of datacontenttype

[duglin]

@alanconway you'll need to sign your commits

[alanconway]

Took a shot at clarifying - whaddya think now?

I went with SHOULD, but I really don't think it makes sense to translate an event with a well-known, if not explicitly stated datacontentype (JSON) into say an AMQP or HTTP binary message with a blob of bytes and no clues what to do with them.

[duglin]

Does this address #519 as well?

[alanconway]

Does this address #519 as well?

I think it does.
@deissnerk do you agree?

[alanconway]

CI failure is an unresponsive external link: https://goextend.io
It's still down 503.

[duglin]

Yeah, I noticed that and was hoping it was a temporary thing but if it lasts a day or two more I'm gonna just remove that link from our docs

[deissnerk]

@alanconway I think it is a prerequisite to address #519. If this PR with its definition for formats gets accepted, the AMQP format could even be removed and the type mapping for attributes be moved over to the AMQP protocol binding. As long as the AMQP format remains protocol specific and does not define a content-type on its own, the only AMQP values I could think of, would be String and Binary. I don't see any advantage in this compared to binary mode where CE data is always put into AMQP data.
Btw the term transport occurs in file names, too. Do we need follow-up PRs to adjust terminology in all the protocol bindings?

[alanconway]

@alanconway I think it is a prerequisite to address #519. If this PR with its definition for formats gets accepted, the AMQP format could even be removed and the type mapping for attributes be moved over to the AMQP protocol binding.

That would be my preference.

As long as the AMQP format remains protocol specific and does not define a content-type on its own, the only AMQP values I could think of, would be String and Binary. I don't see any advantage in this compared to binary mode where CE data is always put into AMQP data.

The current spec suggests (and I agree) that you set content-type and use a single data section for the body. That means that AMQP types (even binary and string) are never used as data - there are no value-section messages. I would be forgiving on incoming messages and accept string or binary value-sections as if they had been data sections - some AMQP APIs hide those distinctions from the user.

Btw the term transport occurs in file names, too. Do we need follow-up PRs to adjust terminology in all the protocol bindings?

That's above my pay-grade guvnor.

[duglin]

rebase needed

[clemensv]

LGTM

[duglin]

Approved on the 10/10 call